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

In general, the deeper something is in the substrate (the more widely distributed it is), the more inertia it has, but the flip side to that is that if there are roughly analogous standards and one is losing traction, the opportunity for fixing the diminishing standard increases. It may very well be that an XML 3.0 may be feasible, especially if it the changes involved mostly had to do with codifying the best of the work-arounds. Fewer people are starting up XML projects, so the pressure to stay conformant is smaller.

JSON right now is where XML was a decade ago: there are too many people wanting to do too many things with it, and the limitations that JSON has are beginning to break applications that become reliant upon what amount to kludge fixes. XML is still better for narrative content, it is better for managing DOMs, and it works better for dealing with the complex issues of translating from one ontology to another than JSON does. There is currently nothing in the JSON world that has the expressivity of XPath, there is certainly nothing that comes close XSLT, and even the JSON community's attempts at a schema language are laughable.

I'm also watching what's happening with SHACL, and think that there is some definite synergy between that standard, XSD and XSLT. I find it interesting that SHACL is beginning to be used even within the JSON community, which tends to be notoriously phobic about anything that can't be expressed in curly brackets or square braces.

Kurt Cagle

Community/Managing Editor

Data Science Central, A TechTarget Property

kcagle@techtarget.com or kurt.cagle@gmail.com

443-837-8725

On Fri, Dec 31, 2021 at 10:11 AM Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

On Fri, Dec 31, 2021 at 12:14 PM Michael Kay <mike@saxonica.com> wrote:
>
>> 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.

Because the objects in JSON have no type names you can't subtype them.
If you cannot subtype you do not have the representational power needed for an OO data model.

The rise of JSON seems coincident with the decline of data modelling.

Is there a causative relationship at play here and if so in what direction.