XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] It's too late to improve XML ... lessons learned?

Also, where there are no type names it’s much harder to put a conceptual (ie, abstract) data hierarchy together that relates to the schema only. 

Without types, all data hierarchies are actual - ie, for a specific implementation - rather than abstract, for a category of implementations.

Thus (at least, this is how I read it), Liam’s allocation of JSON for implementation-specific data specifications (and thus also vendor-, or implementation-specific APIs) and XML for standardised (vendor-, or implementation-neutral) ones.



On 1 Jan 2022, at 4: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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS