RE: [EXT] Re: How long before services sending/receivingXML mi

From: Nora M Dowling <ndowling@mitre.org>
To: Kurt Cagle <kurt.cagle@gmail.com>, "ihe.onwuka@g..."<ihe.onwuka@g...>
Date: Fri, 12 Nov 2021 20:56:29 +0000

Play the video

From: Kurt Cagle <kurt.cagle@gmail.com>
Sent: Friday, November 12, 2021 2:43 PM
To: ihe.onwuka@g...
Cc: Peter Flynn <peter@s...>; xml-dev <xml-dev@l...>
Subject: [EXT] Re: How long before services sending/receiving XML might need replacement?

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@t... or kurt.cagle@gmail.com

443-837-8725

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

On Fri, Nov 12, 2021 at 5:37 AM Peter Flynn <peter@s...> 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?

Attachment: smime.p7s
Description: application/pkcs7-signature

References:
- Re: How long before services sending/receiving XML mightneed replacement?
  - From: Mukul Gandhi <mukulg@softwarebytes.org>
- Re: How long before services sending/receiving XML might need replacement?
  - From: Marcus Reichardt <u123724@gmail.com>
- Re: How long before services sending/receiving XML mightneed replacement?
  - From: Peter Flynn <peter@silmaril.ie>
- Re: How long before services sending/receiving XML mightneed replacement?
  - From: Ihe Onwuka <ihe.onwuka@gmail.com>

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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Subscribe in XML format

RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >