Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] JSON (was Re: [xml-dev] 10th anniversary of the annoucementof XML ..need help)

From: Tahir Hashmi <tnhashmi@-----.--->
To: Michael Champion <mchampion@-------.--->
Date: 6/8/2006 9:16:00 AM
On 06/08/06 11:06, Michael Champion wrote:

> 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.

Universality is tricky business, though. It's not possible to wish
something into "universal" status.

> 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.

Why do you think JSON will hit a brick wall? It's not tough, if not
easier, to HTMLise JSON objects because JS is available more easily
than XSLT. What I mean is that if you're using JSON, your data is
accessible to more browsers than XML (unless you apply XSLT on the
server side, which then becomes a case in favour of (X)HTML rather
than XML).

> 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

This makes sense.

> soooo 1990's. Use an alternative where it solves a real problem and

JSON solves a real problem of object serialisation and interchange
without resorting to binary or difficult-to-read representations. APIs
exposed over HTTP need to exchange messages that contain objects more
often than they need to exchange documents and XML isn't the most
optimal way to do it.

I used to use var_dump for debug tracers in my PHP scripts but I
switched to json_encode because it prints everything in one line, yet
is much easier to read. XML? Heh, won't even dare use it for dumping
objects etc.

> doesn't create worse interop problems, but invest any excess energy
> toward improving XML, incrementally and hopefully in a
> backwards-compatible way.

Maintaining things in a backward compatible manner soon hits
limitations in terms of what can and can not be done. XML has hit the
wall where syntax is concerned. E.g. it's awfully irritating to write
<foo>...</foo> when it could've been <foo>...</> (yeah, nXML mode
helps a lot there). It's even more irritating to read that stuff when
the tag soup takes up 70% of the visible text.

-- 
Tahir


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent