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

[Marcus Reichardt <u123724@gmail.com>]

Hmm idk ...

Today's predominant JS framework is still React, and React apps almost
always use JSX for templating, which originally stands for "JavaScript
XML" even though the XML association appears less pronounced.

Happy New Year,
M. Reichardt
sgml.io

On 1/2/22, 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 <http://voice.google.com/calls?a=nc,%2B14438378725>
> <http://voice.google.com/calls?a=nc,%2B14438378725>
>
>
> 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.
>>
>