6 ms·

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 clea

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.

WorkLifeBalance 8y ago
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.
- zaarn 8y ago
  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.
  - tannhaeuser 8y ago
    No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.
    - zaarn 8y ago
      There is also JSON-schema.org if you don't like RDF/LD.
  - majewsky 8y ago
    Also https://swagger.io/ https://swagger.io/
- asavinov 8y ago
  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.
  - dragonwriter 8y ago
    Pretty much any time I've seen something like this, relevant inner element of the book is: <authors> <author>... <author>... </authors>
    - asavinov 8y ago
      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.
      - Mikhail_Edoshin 8y ago
        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.
- ainar-g 8y ago
  There is a draft of JSON schema: http://json-schema.org/ http://json-schema.org/. And there are working implementations.
- lmm 8y ago
  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.
lkuty 8y ago
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.
- asavinov 8y ago
  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.
- tannhaeuser 8y ago
  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.
atakiel 8y ago
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 https://youtu.be/rI8tNMsozo0?t=28m5s

WorkLifeBalance 8y ago

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.

zaarn 8y ago
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.
- tannhaeuser 8y ago
  No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.
  - zaarn 8y ago
    There is also JSON-schema.org if you don't like RDF/LD.
- majewsky 8y ago
  Also https://swagger.io/ https://swagger.io/
asavinov 8y ago
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.
- dragonwriter 8y ago
  Pretty much any time I've seen something like this, relevant inner element of the book is: <authors> <author>... <author>... </authors>
  - asavinov 8y ago
    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.
    - Mikhail_Edoshin 8y ago
      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.
ainar-g 8y ago
There is a draft of JSON schema: http://json-schema.org/ http://json-schema.org/. And there are working implementations.
lmm 8y ago
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.

lkuty 8y ago

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.

asavinov 8y ago
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.
tannhaeuser 8y ago
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.

atakiel 8y ago

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 https://youtu.be/rI8tNMsozo0?t=28m5s