[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message]

ANSWERS to "What's wrong with XQuery" question

Martin Probst mail at martin-probst.com
Mon Jul 26 11:14:12 PDT 2010

  ANSWERS to "What's wrong with XQuery" question
James Fuller <http://x-query.com/mailman/listinfo/talk> wrote:
> we need to make it very easy to go from XML->JSON and back

The trouble with that is the edge-labelled vs. node-labelled tree
problem. In XML, labels (tag names) stick to the individual nodes, in
JSON, those names stick to the edges that connect nodes. The data
formats are incompatible on a relatively low level. You'll have to
find a way to express mixed content and repeating elements in JSON,
and likewise a way to express the JSON data structures (maps, lists)
in XML. And on top of that, even on the lowest level we have
incompatibilities, for example JSON allows key values that are not

*** on a side note, I think this is also why JSON has so much more
uptake for web programmers and other communities sending programmatic
data around. Edge-labelled trees are trivial to map into most
programming language's object models (they avoid the object<->XML
impedance mismatch), and I think they are also closer to how people
think about the world around them in general. ***

Effectively, you can either have a horrible JSON format that covers
most of XML (even if we decide to ignore attributes vs elements,
entities, and so on), and no one will want to use it. Or you can
decide to have a relatively cumbersome XML format that captures all
the semantics of JSON docs.

In end effect, both formats will be ugly and more or less annoying to
program against with the regular tools for the respective language.
Also, these conversions will be leaky: if someone decides to change
something in the XML representation of a JSON document, it might no
longer be possible to map that back into JSON. Ouch.

It's not really hard to define an acceptable mapping for a specific
given format, but a general mechanism will be ugly and hard to use. I
don't think defining a mechanism that will always be hard to use and
probably introduce many minor issues is necessarily a good idea.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.