[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: JSON (was Re: 10th anniversary of the annoucemen

• To: XML Developers List <xml-dev@l...>
• Subject: Re: JSON (was Re: 10th anniversary of the annoucementof XML ..need help)
• From: Michael Champion <mchampion@x...>
• Date: Wed, 07 Jun 2006 22:36:28 -0700
• In-reply-to: <20060607215749.41707.qmail@w...>
• References: <20060607215749.41707.qmail@w...>
• User-agent: Thunderbird 1.5.0.2 (Windows/20060308)

Tatu Saloranta wrote:
> Actually, I would disagree... I could see it as one
> possible unqituious simple general data interchange
> format; esp. when data is bound to objects. Unlike
> XML, it's object serialization, or rather just
> struct/value serialization (since it's missing object
> identity).
Those who wish to get out of the XML frying pan might remember the fire 
down below.  XML has many disadvantages, especially for object 
serialization, but those problems pale in comparison to the problems of 
not having a universal data interchange format. 

XML's main benefit is simply that it is universal, and good enough for 
most types of information even if it isn't optimal for any.  Lots of  
applications might appear at first glance to be all text or all data ... 
but I think XML got  popular partly because there are even more 
requirements for information interchange that are somewhere in the 
middle - some mixture of human readable text and machine processable data. 

I have no issues when JSON is used as a convenient object serialization 
format between components in a relatively tightly coupled distributed 
application, e.g. Google Maps.  Serializing information into a syntax 
that can be directly parsed into JS objects makes sense, for 
optimization if nothing else.  But what happens in more loosely coupled 
scenarios, where somebody else's app, maybe written in a compiled 
language, has to use your data?  What happens when you need to start 
supporting HTML markup of the text fields in those objects?  JSON will 
hit a brick wall, and so will S-Expressions AFAIK.

Sure we *could* (at least in the Microsoft XML processing architecture) 
support XML readers and writers for JSON, S-expressions, godknowshowmany 
binary XML formats, etc. etc. etc. I just can't see how the world would 
be a better place if that happened.  There would inevitably be formats 
that one platform or toolset supports that others don't (ahem, like XML 
1.1 for better or worse).  The only way this could get us out of the 
frying pan yet avoid the non-interoperable format fire would be if XML 
1.0 is the fallback that *everyone* supports if JSON, S-expression, or 
EXI format handshake fails.

I hate to sound like a crusty old conservative, but it would be nice if 
people didn't jump on the JSON  (etc.) bandwagon just because it's 
trendy and fun and helps differentiate one's message ... and XML is 
soooo 1990's. Use an alternative where it solves a real problem and 
doesn't create worse interop problems, but invest any excess energy 
toward improving XML, incrementally and hopefully in a 
backwards-compatible way. 

• Follow-Ups:
  • Re: JSON (was Re: 10th anniversary of the annoucement of XML ..need help)
    • From: PA <petite.abeille@g...>
  • Re: JSON (was Re: 10th anniversary of the annoucementof XML ..need help)
    • From: Tahir Hashmi <tnhashmi@g...>

• References:
  • Re: JSON (was Re: 10th anniversary of the annoucement of XML ..need help)
    • From: Tatu Saloranta <cowtowncoder@y...>

• Prev by Date: Re: skipping the null node values in a DOM Tree
• Next by Date: Re: skipping the null node values in a DOM Tree
• Previous by thread: Re: JSON (was Re: 10th anniversary of the annoucement of XML ..need help)
• Next by thread: Re: JSON (was Re: 10th anniversary of the annoucementof XML ..need help)
• Index(es):
  • Date
  • Thread