[occi-wg] Simple JSON rendering for OCCI

[Alexander Papaspyrou]

Alexis,

JSDL has shown that extensions work fine even (sigh) with XML  
namespaces, without breaking interop.

Leaving extension points with xsd:any with namespace #other and lax  
content allows for easy interop by just ignoring vendor-specific stuff.

-Alexander

Am 14.05.2009 um 21:01 schrieb Alexis Richardson <alexis.richardson at gmail.com 
 >:

> Sam,
>
> On Thu, May 14, 2009 at 7:40 PM, Sam Johnston <samj at samj.net> wrote:
>>
>>>
>>> Extensibility is the enemy of interoperability.  We should XML for
>>> Integration at the edge.  NOT for the interop core.
>>
>> Rubbish - we need extensibility and there is no "edge"
>
> Thanks Sam.
>
> I am not arguing against extensions, I am arguing that dealing with
> them needs to be done so as to not make it easy to break interop.
>
> The reason that extensibility is the enemy of interoperability is that
> if two users extend the core protocol then:
>
> 1. If they do not interoperate then this is really hard to debug
> without appealing to the users who made them.  "Really hard" meaning
> "impractical to the point of hampering adoption".
>
> 2. If they appear to interoperate then we still cannot tell if they
> are actually interoperating because the semantics of their extensions
> may not be the same.
>
> But, users want extensions.  The solution to this problem is to allow
> extensions but not require them to be in the core protocol.  Not being
> in the core protocol, means being on the 'edge', which is an
> appropriate term for 'not core' or 'at the edge of the network' to be
> more specific.
>
> Does TCP have extensions?  No.  (Or if it does people apparently don't
> use them because it would break interop)
>
> Does WS-* have extensions?  Yes.
>
> Please - anyone - tell me what is wrong with the above argument.
>
> Sam, I liked Gary's diagrams - perhaps you did too which suggests some
> common ground or that we are arguing at cross purposes?
>
> alexis
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg