Re: [xml-dev] It's too late to improve XML ... lessons learned?

[Michael Kay <mike@saxonica.com>]

> 
>> The biggest question beyond that for me is, who is to be in control
>> of the format of the data? If it's the application developer at the
>> receiving end, use JSON. If the data is to be vendor-neutral and have
>> a long lifespan, consider XML.
> I'd like to add that to the XML FAQ page on JSON, if you would permit,
> pretty please.
> 

It's an interesting remark but we need to understand why this should be the case.

Is it just that JSON doesn't have a mature and widely accepted schema language, or is there something else? Is there something intrinsic about XML that makes it better suited to creation of a vendor-neutral and long-lifespan application standard?

I'd suggest three possible factors that come to mind, but there may be others.

(1) XML has element names, JSON doesn't - the objects in JSON have no type-name. They are distinguished either by their internal structure (what properties exist), or by their role (where do they appear in the containing structure). This might seem a rather trivial difference, but I think it has far-reaching implications. Structural components can't be easily reused unless they can be named. Named elements can be used in more than one place, and the reuse is evident by the use of the common name. This also allows processing logic (such as XSLT template rules) and validation rules to be associated with the name. It also provides a link between the implementation data structure and the conceptual data model: element names tell you which bits of data in a message correspond to which real-world objects.

(2) XML is less sensitive to changes in the cardinality of properties. Allowing a person to have a second employer or occupation or surname or phone number, or a book to have multiple titles or publishers, doesn't involve an incompatible change with XML as it does in JSON. Cardinality changes like this are very common as a data model evolves (I remember Bill Kent talked about "one to one-and-a-bit relationships" and the difficulty of handling them in relational databases).

(3) Namespaces. You all know that I hate the way namespaces were implemented in XML, but they do have benefits, and one of them is to allow vendor extensions to a standard vocabulary. I believe this capability has been extensively exploited in standards like FPML, and this enables a standard to be used for interoperability without precluding local extensions.

Any others?

Michael Kay
Saxonica