[occi-wg] Simple JSON rendering for OCCI

Alexis Richardson alexis.richardson at gmail.com
Wed May 13 04:00:46 CDT 2009


David,

On Wed, May 13, 2009 at 2:22 AM, M. David Peterson <xmlhacker at gmail.com> wrote:
> It just hit me.  JSON is utterly useless in this space.
>
> ...  The problem space here requires that there be in
> place the ability to take two function names which seemingly provide the
> same functionality, carry the same name, and yet couldn't be further apart
> in regards to the action they represent on each of the systems in which they
> live, and make a clear distinction as to what each particular function call
> actually does.

No it does not require that ability.

That is exactly what we don't want to see because it will break
interoperability.

You are talking about INTEGRATION.  In your example the requirement as
I understand it is for two different providers to make a local
interpretation of a name.  This is exactly why we should encourage
extensibility at the edge - where the provider is in control and the
name has all the context that it needs available to it.

But we need to keep local interpretations local.  To prevent
confusion, there can be NO scope for ambiguity in the common core.
That is why the interop core format benefits from NOT being user
extensible or namespaceable or anything else like that.  TXT is almost
good enough, but IMO in the end we benefit from a bit more structure
out of the box.

If we use XML for the interop core then we need a way to restrict
users from extending it at runtime.  If we use JSON for the interop
core then there can be no confusion because users will be forced to do
their XML extensions at the edge integration points.



> In relation to XML, this particular problem was solved nearly
> 10 years ago with the introduction of XML namespaces, something JSON is
> simply not capable of dealing with at this stage of the game.

Namespaces would be disastrous for interop and a great way to achieve WS-fail.

Namespaces are a win for integration.



>>> requires much less code to parse,
>
> As would any system that didn't have to differentiate between two words
> spelled exactly the same and yet had two completely different meanings.

Yes, this is why JSON is perfect for interop.

The requirement for interop, is this: When two parties say the same
thing to each other, they MUST mean the same thing.




> Sorry folks, JSON won't work in this space. Unless the goal of the OCCI is
> finding a way for system vendors to agree upon homogenizing their system
> API's? I'm pretty sure it's not, and in this regard, JSON simply will not
> work. Period.

No, the goal is interoperability.  This does not imply homogenization.

See the recent mails from Randy and Ignacio on another thread.



> --
> /M:D
>
> M. David Peterson
> Co-Founder & Chief Architect, 3rd&Urban, LLC
> Email: m.david at 3rdandUrban.com | m.david at amp.fm
> Mobile: (206) 999-0588
> http://3rdandUrban.com | http://amp.fm |
> http://broadcast.oreilly.com/m-david-peterson/
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>



More information about the occi-wg mailing list