Re: [xml-dev] How long before services sending/receiving XML might need replacement?

At 2021-11-12 11:42 -0800, Kurt Cagle wrote:
>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.

In 2017 I summarized my personal opinion 
regarding "most programmers today" using JSON 
because it makes their job easier, it doesn't 
make the user's job easier when dealing with information exchange:

https://www.linkedin.com/pulse/horses-courses-perspective-xml-vs-json-discussion-ken-holman 


TL;DR - JSON is for tight coupling in 
programming, XML is for data description in interchange.

The subject line sending/receiving doesn't 
indicate whether the exchange is happening inside 
of the computer (coupling programs) or outside of 
the computer (interchange between information systems).

. . . . . Ken

>  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
><mailto:> 
>or <mailto:>
>443-837-8725
>
>
>On Fri, Nov 12, 2021 at 8:05 AM Ihe Onwuka 
><<mailto:>> wrote:
>
>On Fri, Nov 12, 2021 at 5:37 AM Peter Flynn 
><<mailto:>> 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>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?
>


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |