Re: [xml-dev] It's too late to improve XML ... lessons learned?

[Ihe Onwuka <ihe.onwuka@gmail.com>]

The problem is not what web developers want for themselves, rather that everybody should want what web developers want. 

In reality all this does is shift the impedance mismatch on to other communities that are less adept at whining about it.

So now we have the asininity of JSON extensions for SQL and the absurdity of people who want to introduce JSON into XML information exchanges being taken seriously.

On Sun, Jan 2, 2022 at 5:09 PM Kurt Cagle <kurt.cagle@gmail.com> wrote:

Ihe,

Oh, yeah. I've been dealing with this complaint for years. Part of it becomes self-fulfilling - no one uses straight _javascript_ anymore, not for web development, anyway. Instead they use some complex JS framework, and the framework, of course, is geared to a particular data format, almost invariable built around JSON. No one likes XML because they believe, with a bit of justification, that if they work with XML, they are also working with cumbersome XML DOM commands rather than XPath (because XPath is VERY foreign to the way they think about information). 

Frankly, what we should have done years ago was create an XPath2JSON command that would automatically turn an XML DOM into a flat JSON structure, and made it a part of the XPath spec.  I'm sure something like that exists somewhere in the vast Node.js wilderness, but by now web developers reject XPath simply because of the first letter of the name.

Kurt Cagle

Community/Managing Editor

Data Science Central, A TechTarget Property

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

443-837-8725

On Sat, Jan 1, 2022 at 4:01 AM Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

On Thu, Dec 30, 2021 at 8:46 PM Liam R. E. Quin <liam@fromoldbooks.org> wrote:

>
> But it's mostly irrelevant at this stage; a historical warning about
> standards development. If you want to exchange data nowadays, the
> trend seems to be to use JSON, unless your processes are already
> using XML for other purposes.

Linked Data has some merits. 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.

The question that should be asked is apart from the web application developer what use case is really crying out to be sent JSON.

Why would an enterprise with applications in which the data's ultimate source and destination is a normalized Oracle or SQL Server want to receive or store any of that data in JSON. 

Why would an information exchange application (govt or private sector) standardized on a contract specified in XML Schema (fpML, ACCORD, NIEM, MUREX) want to receive or store any of that data in JSON. 

Why would an application with triple store end points want to receive data  in JSON. 

The burden of the impedance mismatch (real or imagined) the Dev is agitating to avoid is being transferred to the less vocal stakeholders. It just so happens that they are the people who either use or own the data but they end up being force fed something that suits the developer with a side helping of learn how to program an API for good measure. 

It's a bit of a  nonsense that the data needs of an application or enterprise are being determined on the basis of what is good for the devs and hence data is being trafficked in a format that has the ecosystem of an illiquid currency.