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

Hi Dimitre,
   Nice thoughts in your mail below.

I think, its good to discuss pros and cons of XML vs JSON on an XML list like this, since both XML and JSON share a common theme; i.e a data representation format. The XML folks can learn from the simplicity of JSON format, and can design simple XML formats for specific requirements, and JSON folks can learn from XML about how to scale JSON solutions for complex requirements for which XML is seemingly suited.

On Wed, Jun 27, 2018 at 3:01 AM, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
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.



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