David, On Wed, May 13, 2009 at 2:22 AM, M. David Peterson <xmlhacker@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@3rdandUrban.com | m.david@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg