Hacker News Reader

Comment by asavinov | Hacker News Reader

If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent.

In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a very typical example which is more than an anti-pattern:

    <books> 
        <book id="1"><title>XML is evil</title></book> 
        <book id="2"><title>XML considered harmful</title></book> 
    </books>

Here we see that semantically <books> is a collection while <book> is a tuple (where <title> is an attribute). Yet, they use one and the same structural construct. XML does not enforce the dual semantics of sets and tuples, and therefore XML files are frequently a conceptual mess. The above example is essentially wrong but XML does not care.

View on HN

XML without schema are a mess.

XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular.

Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity.

Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to expensive bugs in production, but in the real world the ability to mostly ignore types lets people get things done in a more hackish / amatuer way which eases the learning curve and helps popularity.

JSON does have Schemas and Validation (JSON-LD and RDF I believe are the relevant standards here), which are backwards compatible with parsers that don't support it (though the number of parsers that do is sadly rather low).

In principle you still get schema and validation.

No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.

There is also JSON-schema.org if you don't like RDF/LD.

Also https://swagger.io/

Typing (enforcing constraints) is an important aspect. But even without typing XML has one fundamental flaw. You are not able to (correctly) represent tuples with attributes which are sets. In XML, tuple attributes are properties, for example:

    <book id="1" title="XML"> -- object or object

Now let us assume that I want to have a list of authors as a property:

    <book id="1" title="XML" authors=["Me", "My Friend"]> -- NOT SUPPORTED

Therefore, we use a workaround (a crime actually):

    <book id="1" title="XML"> 
        <author>Me</author>
        <author>My friend</author>
    </book>

Now a book is a collection where authors are members (IS-IN relationship). This is not what we wanted. Our goal was to have an attribute "authors" which is a collection.

Pretty much any time I've seen something like this, relevant inner element of the book is:

  <authors>
    <author>...
    <author>...
  </authors>

It is again a workaround because <authors> is a member of a collection - it is not a tuple attribute. Which suggests that we cannot enforce this separation and an application has to understand itself which element is an object property and which element is a member of a collection.

You're trying to impose an arbitrary model on XML.

XML grew from markup languages. It's as if we took some text, parsed it, and then store the resulting syntax tree along with the text. Here elements are non-terminals of the grammar and element attributes are additional augmenting properties of those non-terminals.

The text, of course, does not have to human-readable, it can very well be a sequence of anything, for example, of bits, bytes, words, etc. In XML we'd have to represent these with special elements, something like <byte value="00" /> or <int32 value="12345" />, but once we do this, we can use XML to enclose them into additional non-terminals that tell us what these bytes mean and let us use automated tools to manipulate them.

XML can represent objects, but in its own way: we have to first sort of serialize our object into a sequence and once we have this sequence, we can use XML. The model you seem to be talking about an abstract model of abstract objects in memory. Although memory is technically sequential, we normally ignore this and treat objects as nodes in some graph. This is not the domain of XML; it has to be a sequence to begin with. XML has a concept of IDs and references to IDs and thus can represent graphs reasonably well, but it must be a serialized graph.

So XML is basically a language to express the underlying grammatical structure of an arbitrary sequence. That structure is a tree, but it is based on a sequence nonetheless. It's not quite what abstract objects are in programming; but if you think of files, for example, files are sequences and thus are totally the domain of XML.

> It is again a workaround because <authors> is a member of a collection - it is not a tuple attribute.

Its an element not an attribute, but the set of elements and the set of attributes are both collections.

> Which suggests that we cannot enforce this separation and an application has to understand itself which element is an object property and which element is a member of a collection

It's true that that is not part of bare XML and the nature of attributes vs. elements, even though you want to impose it there.

OTOH to the extent that those words correspond to a well-rounded semantic distinction, it is arguably captured in schema languages, and not mere application-level knowledge.

Which reminds me of the picture[1] on the cat-v.org section about XML.

[1] http://harmful.cat-v.org/software/xml/xml_ascent.png

The article "XML Sucks" containing that Ward Cunningham image is interesting:

http://harmful.cat-v.org/software/xml/

It includes this classic James Clark quote:

“Any damn fool could produce a better data format than XML” – James Clark 2007-04-06

Which Tim Bray discussed in "Any Damn Fool":

https://www.tbray.org/ongoing/When/200x/2007/04/08/James-Cla...

Tim Bray recommended James Clark's Random Thoughts about "Do we need a new kind of schema language?": "If you’re doing original work around the intersection of messaging and programming, you need to read it and think about it."

http://blog.jclark.com/2007/04/do-we-need-new-kind-of-schema...

James Clark writes:

>Some people propose solving the XML-processing problem by adopting an XML-centric processing model, for which the leading technologies are XQuery and XSLT2. The fundamental problem here is the XQuery/XPath data model. I'm not criticizing the WGs' efforts: they've done about as good a job as could be done given the constraints they were working under. But there is no way it can overcome the constraint that a data model based around XML and XSD is just not very good data model for general-purpose computing. The structures of XML (attributes, elements and text) are those of SGML and these come from the world of markup. Considered as general purpose data structures, they suck pretty badly. There's a fundamental lack of composability. Why do we need both elements and attributes? Why can't attributes contain elements? Why is the type of thing that can occur as the content of an element not the same as the type of thing that can occur as a document? Why do we still have cruft like processing instructions and DTDs? XSD makes a (misguided in my view) attempt to add a OO/programming language veneer on top. But it can't solve the basic problems, and, in my view, this veneer ends up making things worse not better.

>I think there's some real progress being made in the programming language world. In particular I would single out Microsoft's LINQ work. My doubts on this are with its emphasis on static typing. While I think static typing is a invaluable within a single, controlled system, I think for a distributed system the costs in terms of tight coupling often outweigh the benefits. I believe this is less of the case if the typing is structural rather than nominal. But although LINQ (or at least newer versions of C#) have introduced some welcome structural typing features, nominal typing is still thoroughly dominant.

>In the Java world, there's been a depressing lack of innovation at the language level from Sun; outside of Sun, I would single out Scala from EPFL (which can run on a JVM). This adds some nice functional features which are smoothly integrated with Java-ish OO features. XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

More words from James Clark on JSON: "Yay" and "Sigh"

http://blog.jclark.com/2010/11/xml-vs-web_24.html

>If other formats start to supplant XML, and they support these goals better than XML, I will be happy rather than worried.

>From this perspective, my reaction to JSON is a combination of "Yay" and "Sigh".

>It's "Yay", because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements. This leaves the developer with three choices, all unappetising:

>live with an inconvenient element/attribute representation of the data;

>descend into XML Schema hell in the company of your favourite data binding tool;

>write reams of code to convert the XML into a convenient data structure.

>By contrast with JSON, especially with a dynamic programming language, you can get a reasonable in-memory representation just by calling a library function.

Even more fun: XML attributes undergo "whitespace normalization"!

https://stackoverflow.com/questions/260436/preserving-attrib...

There is a draft of JSON schema: http://json-schema.org/. And there are working implementations.

XML with schema (and namespaces, which schemata necessitate) is an immense pain to work with. XML with simple elements and no namespaces is actually fine to work with, as is something like thrift/protobuf. I don't think the problem is that XML has schema and validation, it's that it has bad schema and validation.

Yes but in XML we view things as trees, not sets, tuples, or the likes. If you consider stuff as trees, there is not anti-pattern and the example is not wrong, it is correct. It is easy. Maybe we can be a little bit dissatisfied with the choice of attributes vs elements. Of course JSON and its small spec is easier than XML and its bunch of complex recommendations.

Yes, you are right. So the question is which model is better: a tree model (with nodes as flat tuples) or JSON model with nodes being either collections or combinations (with arbitrary nesting). It seems that JSON is more general while XML requires you to map the reality into a tree representation. It is somewhat similar to the relationship between the hierarchical data model and the relational data model.

I think it's more appropriate to say XML is about a grammar description of some information serialization. Whereas JSON starts from concepts such as maps which are higher-level data structures. Also, SGML/XML originally isn't so much about trees as about regular tree languages - where the sequence of elements appearing below a node must satisfy a content model given by a regular expression.

Rich Hickey has a good point in his Rails Conf 2012 "Simplicity Matters" talk[0] - json is just more simple than xml, as it clearly states which parts are maps and which are sequences. Xml has an inherent, implicit order in everything, due to its history as a document markup language.

If you think xml through the lens of jsx pragma style transformation, xml element and it's attributes are more or less a (typed) map. Similarly element's children is an (ordered) sequence. Where as in json you can have maps inside maps, in xml you always have to wrap maps inside an ordered sequence, as maps can only be passed to element as its children.

You can totally use xml without paying attention to the order, but the order is still there, complicating things.

[0] Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey - https://youtu.be/rI8tNMsozo0?t=28m5s

Reply on news.ycombinator.com