OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] use of JSON instead of XML

As a regular programmer I can work with both JSON and XML, but as a
team member I have to respect the team's choices and preferences as
well those of the company/organisation.

Please, don't laugh at me, but the main use case for both XML and JSON
that I have seen in my work is to be used as serialization format. As
a programmer I don't care which serialization format will be used --
only that I get it deserialized into the needed object. As it happens
in most cases / in general, JSON is cheaper (shorter) and corresponds
almost 1:1 to objects, while XML is (slightly) longer and some
documents may not fit easily into an object. Maybe this made regular
programmers to be more willing to use JSON (and again, they really
don't care too much)

On the client, however, it is really much easier to turn a JSON
document into a Javascript object, than to do so with an XML document.
So, for client-side programmers this choice may not be purely

As for REST vs. SOAP, it has been observed that serious (heavy)
financial (needing precision and reliability) systems are known to use
more the SOAP protocol rather than just the more relaxed (thus more
untyped and difficult to validate) REST style. This is why REST is
just an architectural style, while SOAP is a protocol.

What this means is that hidden from our eyes are many
serious/heavy/important proprietary systems that rely heavily on XML
to do useful, precise, complicated processing. Not to mention the
millions of config files in XML format, that are processed, extended,
every second. The chance of them being globally replaced with JSON is
slim, does anyone want to bet on this?

I think it is realistic that no single data format, including XML, is
best for all purposes, thus the subject of this thread seems a little
bit pushing us in the wrong direction.

Maybe now, when the dust has settled, we better know what XML is best
for, and we should be grateful to finally have gained this knowledge.
Maybe XML is the stepping stone to the next even better data format
that some of us will come up with.

This said, my personal preferences are probably well-known. When
writing programs for my consumption I enjoy XSLT/XML/XPath, because
for me personally, this requires the least time and effort to get the
job done.

But for the bigger picture, rather than talk, can we:

Educate most programmers so that they have experienced what we have,
and then probably we would not to have this discussion, nor would we
count our average age.

Like Galois (https://galois.com/) uses exclusively functional
programming to develop their products, found and own a company that
would only use XML / XSLT / XPath / XQuery in developing its products.
Make this a great company that people would love to work for. Or what
was it: "If you build it they will come".

Build the next-age programming tools around XML technology, etc., etc.


On Sun, Jun 24, 2018 at 10:17 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
> Hi all,
>    I've seen in few commercial projects of which I was part recently, and
> here's the trend I saw,
> 1) Architects have been choosing to implement REST services instead of using
> Web Services (using SOAP & XML). Perhaps this is fine with a mobile app, but
> not always in other software applications.
> 2) Architects have been choosing JSON in general, instead of XML as a data
> exchange syntax. Perhaps this is because, JSON is simple to use instead of
> XML.
> My personal feeling is, that people would choose XML when they're developing
> a big software instead of a tiny one. And when good software engineering is
> important.
> It would be nice to know, opinion from this list, about the above points.
> --
> Regards,
> Mukul Gandhi

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS