[
Lists Home |
Date Index |
Thread Index
]
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.
|
