Re: [xml-dev] How long before services sending/receiving XML mightneed r

I have a somewhat different perspective, because of late I'm primarily in the RDF space and working as an inter-enterprise ontologist.

I've started taking the approach when advising clients to concentrate first on the ontology - the entities and relationships that make up the relevant business domain language, then to create multiple serializations for different targets.

If I'm putting together something that will need to be interpreted as a DOM (e.g., working within a browser using web components) then an XML-like language makes a lot of sense) - you can do things with DOMs that are very difficult to do with JSON.

I also think that XML is far better than JSON for working with NIEM and similar standards. If I'm just seeking or updating information, I'll usually use JSON and GraphQL on the front end, and RDF on the back end, with the GraphQL engine coupled to a SHACL bridge.

If I'm working on a data model I almost always start with Turtle to build up prototypes, then reverse engineer from there into SHACL, usually via SPARQL. The key thing in all cases is to make sure that the ontology is consistent between interactions.

JSON is a necessary evil because most programmers have been trained to NOT be systemic thinkers, but rather to concentrate on their own particular module or component. JSON fits this mentality well because JSON serializes cleanly into _javascript_ objects, and reasonably well into Python objects. XML has a complex DOM that's more difficult to navigate because the W3C assumed that most people would choose to use XPath rather than the low-level DOM primitives, but XPath notation was too different from _javascript_ dot notation conceptually, so you STILL have people who prefer using DOM (or worse, CSS selectors)

Of course, I'm an information architect, not a programmer, so what do I know. :-)

Kurt Cagle

Community/Managing Editor

Data Science Central, A TechTarget Property

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

443-837-8725

On Fri, Nov 12, 2021 at 8:05 AM Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

On Fri, Nov 12, 2021 at 5:37 AM Peter Flynn <peter@silmaril.ie> wrote:
On 12/11/2021 08:12, Marcus Reichardt wrote:
> At the risk of sounding pedantic, i don't agree at all with what you
> said, Mukul ;)
>
> [...] XML's other uses - as a preferred payload format for web
> services, and as go-to language for configuration and other metadata
> - have been on the decline for about 15 years as well.

Many of these were bandwagons (with the exception of text delivery).
Very attractive at the time ("Look! Only one format!").

What is being overlooked is that in the context of government IT, factors relating to the publishing and SGML heritage of XML are a bit of a red herring.
Aside from the core use case of contracts and validation, XML usage for document exchange in government IT derives from it offering schema technology that was intentionally designed to support object oriented modelling use cases.
This is explicitly set out in Section 5 below which variously and explicitly mentions the concepts of class, inheritance and derived types.

https://www.w3.org/TR/NOTE-xml-schema-req

JSON OTOH was designed with a set of disjoint primitive types and whereas JSON Schema may have presented an opportunity to address deficiencies in it's OO modeling capability, it was deliberately not taken.
That people seriously expect to be able to slot JSON into a complex modelling use case that it was intentionally not designed for is testament to the degree of FUD surrounding exactly what JSON should be used for.
Beyond the noise of JSON advocacy, what else is backing that up?