|
At least, this is what I have found when putting XML schemas together, and deciding between using internal (un-named) types and external, named ones. The internal ones are just that - internal - and thus in a way, an internal implementation detail, whereas
the named types are somehow “lifted” into the public API and intended for re-use. Because they’re intended for re-use, or at the very least for standardisation, they are less implementation-specific and more fully part of the conceptual data model.
Similarly when putting together data structures inside applications (that have nothing to do with XML).
But I might be reaching here...
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.
>
>> 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.
|
