6 ms·

> [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language. I disagree with you. A XML file is, by

> [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language. I disagree with you. A XML file is, by definition, a [context-free grammar](https://en.wikipedia.org/wiki/Context-free_grammar https://en.wikipedia.org/wiki/Context-free_grammar), the same type of grammars used to specify programming languages. I will make it clearer with the examples below: /* a simple data structure */ struct Point { int x; int y; }; <point> <int name="x"></int> <int name="y"></int> </point> /* a recursive data structure */ struct Person { std::string name; std::vector<Person> children; }; <person> <string name="name"></string> <vector type="person"> <person> <string name="name"></string> <vector type="person"> </vector> </person> <person> <string name="name"></string> <vector type="person"> </vector> </person> </vector> </person> To me, it is immediate to see the correct data structure in both examples. If I had to write the second one in JSON, for instance, I would lose the "template type-information" of the list (vector).

rini17 6y ago
But in practice it ends up any adhoc combination of <point><x>value</x>...</point> or <class name="point"><property name="x" value="value"></property>...</class> You can argue this should not happen, that it's not valid XML, etc...but being so verbose and readable, it tends to attract abuse and then hate.
- guiraldelli 6y ago
  And how is it different from, let us say, the current's sweetheart, JSON? (The comparison is not exclusive to JSON, though.) JavsScript Object Notation makes a lot of sense to describe... The JavaScript objects. But, nowadays, I see it universally applied. As a recent personal experience, I had to use it to serialise communication between a C++ and a Java application---two statically typed languages, with basic types similar among each other but different from JavaScript. To set the contract between the two applications, I had to write a JSON spec [1], which is written in... JSON. That was an abstruse and abusive use of JSON, in my opinion. Then comes `jq` and its own notation, in which I suffer to do the basics of a simple XPath---e.g., return all the objects of a certain kind (i.e., a tag) in any level you find it. Abuse happens [2] because there is a human behind it, especially under the lens of the adage "if all you have is a hammer, everything looks like a nail". The problem I see in this discussion is that people either want a "magic tool" that works at all cases, or they want to control the human behind it. In my experience, it is difficult to get both: generality does not play well with constraint. --- <digression> I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5]. </digression> --- [1]: http://json-schema.org/ http://json-schema.org/ [2]: I believe this is a Fibonacci series: https://www.xorpd.net/pages/xchg_rax/snip_01.html https://www.xorpd.net/pages/xchg_rax/snip_01.html [3]: http://blog.aerojockey.com/post/iocccsim http://blog.aerojockey.com/post/iocccsim [4]: https://www.arp242.net/the-art-of-unix-programming/#id2907428 https://www.arp242.net/the-art-of-unix-programming/#id290742... [5]: https://tools.ietf.org/html/rfc822 https://tools.ietf.org/html/rfc822
  - kanox 6y ago
    > To set the contract between the two applications, I had to write a JSON spec [1], which is written in... JSON. That was an abstruse and abusive use of JSON, in my opinion. The XML equivalent is an XML schema, also written in XML. This is pretty decent as document validation goes. > I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5]. You linked to formats which don't even support nesting. If you roll your own markup it's going to be brittle and people are going to parse it with regexps.
- GoblinSlayer 6y ago
  JSON has more degrees of freedom due to more literal types and structures, you can build more contrived documents with it.
  - kanox 6y ago
    How so? The JSON model is much more restricted than XML. For example: * In XML an "object property" can be represented as either an attribute or an element, in JSON only dicts can have attributes. * In XML elements can contain a mix of text and child elements. For serializing objects this is almost never desired. * JSON has a single way to define lists, in XML you need to roll your own.
    - GoblinSlayer 6y ago
      In JSON "object property" is not synonymous to "dict", dict is just one of many ways to express object properties. JSON can contain a mix of differently typed objects too, which is similarly meaningless for serialization. And serialization is not the only usage of json. JSON has a concept of list, but lists can be defined in many ways. And list is not the only collection type one might want to express in json. For example, is package dependency list a list or a dict?
Sander_Marechal 6y ago
That's one way to map that to XML. But there are a dozen other ways to map it as well, and all equally (un)usable.
MaxBarraclough 6y ago
> context-free grammar, the same type of grammars used to specify programming languages As I understand it, few modern programming languages have context-free grammars.
thinkharderdev 6y ago
Of course you can serialize a struct to XML in an idiomatic way but a lot of the time you don't. You get an XML document produced by someone else that maps to a horribly non-idiomatic representation as an object in your language runtime. I have personally seen lists/arrays serialized to XML in a bewildering variety of ways. The advantage of JSON I think is that the mapping to data structures is relatively straightforward and idiomatic so when you are creating a type to represent a JSON document you are receiving from some external source, you are likely to get something that looks reasonable.
Joker_vD 6y ago
But nobody marshals like that (except you, obviously)! Your Person struct is usually marshalled like this: <person> <name></name> <children> <person> <name></name> <children> </children> </person> <person> <name></name> <children> </children> </person> <children> </person> or, if you're unlucky, even like this: <person> <name></name> <person> <name></name> </person> <person> <name></name> </person> </person> with implicit arrays. Not that your scheme is much better, really, why are you putting you favourite language's types in the tags? My favourite one uses lists and binaries instead of vectors and strings, you know.
- guiraldelli 6y ago
  Thank you for improving it. In fact, I prefer your first example and if I had thought about 30 extra seconds, I probably would have written something similar. > Not that your scheme is much better, really, why are you putting you favourite language's types in the tags? My favourite one uses lists and binaries instead of vectors and strings, you know. Because that was just an example that came up in my mind in less than 10 seconds to make my point. I am glad that people understood my point and even came up with better solutions to make my argument even stronger.
  - piaste 6y ago
    > I am glad that people understood my point and even came up with better solutions to make my argument even stronger. Your smugness is unwarranted. You claimed that XML has an obvious, natural mapping to data structures. After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons. Your argument didn't come out in very good shape from that exchange.
    - guiraldelli 6y ago
      > You claimed that XML has an obvious, natural mapping to data structures. That is an (i.e. your) interpretation of what I said. Please re-read my text below, in context. >>> [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language. >> [...] >> A XML file is, by definition, a context-free grammar, the same type of grammars used to specify programming languages. >> [...] >> To me, it is immediate to see the correct data structure in both examples. > After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons. > Your argument didn't come out in very good shape from that exchange. I disagree with you: both understood pretty well my data structures and came up with even clearer notation, making my point that it is a suitable grammar representation for data structures. > Your smugness is unwarranted. Seriously?
kanox 6y ago
You're effectively defining a serialization format using a subset of xml. You can do that with JSON as well, adding "type" properties as required. The problem is that everybody has their own subset of xml for serializing objects, while for json you can load arbitrary json into a straight-forward tree of dicts, lists and literals. If receive arbitrary xml the only way to process it is with xml-specific tools because the object model does not map to any programing language.

rini17 6y ago

But in practice it ends up any adhoc combination of <point><x>value</x>...</point> or <class name="point"><property name="x" value="value"></property>...</class> You can argue this should not happen, that it's not valid XML, etc...but being so verbose and readable, it tends to attract abuse and then hate.

guiraldelli 6y ago
And how is it different from, let us say, the current's sweetheart, JSON? (The comparison is not exclusive to JSON, though.) JavsScript Object Notation makes a lot of sense to describe... The JavaScript objects. But, nowadays, I see it universally applied. As a recent personal experience, I had to use it to serialise communication between a C++ and a Java application---two statically typed languages, with basic types similar among each other but different from JavaScript. To set the contract between the two applications, I had to write a JSON spec [1], which is written in... JSON. That was an abstruse and abusive use of JSON, in my opinion. Then comes `jq` and its own notation, in which I suffer to do the basics of a simple XPath---e.g., return all the objects of a certain kind (i.e., a tag) in any level you find it. Abuse happens [2] because there is a human behind it, especially under the lens of the adage "if all you have is a hammer, everything looks like a nail". The problem I see in this discussion is that people either want a "magic tool" that works at all cases, or they want to control the human behind it. In my experience, it is difficult to get both: generality does not play well with constraint. --- <digression> I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5]. </digression> --- [1]: http://json-schema.org/ http://json-schema.org/ [2]: I believe this is a Fibonacci series: https://www.xorpd.net/pages/xchg_rax/snip_01.html https://www.xorpd.net/pages/xchg_rax/snip_01.html [3]: http://blog.aerojockey.com/post/iocccsim http://blog.aerojockey.com/post/iocccsim [4]: https://www.arp242.net/the-art-of-unix-programming/#id2907428 https://www.arp242.net/the-art-of-unix-programming/#id290742... [5]: https://tools.ietf.org/html/rfc822 https://tools.ietf.org/html/rfc822
- kanox 6y ago
  > To set the contract between the two applications, I had to write a JSON spec [1], which is written in... JSON. That was an abstruse and abusive use of JSON, in my opinion. The XML equivalent is an XML schema, also written in XML. This is pretty decent as document validation goes. > I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5]. You linked to formats which don't even support nesting. If you roll your own markup it's going to be brittle and people are going to parse it with regexps.
GoblinSlayer 6y ago
JSON has more degrees of freedom due to more literal types and structures, you can build more contrived documents with it.
- kanox 6y ago
  How so? The JSON model is much more restricted than XML. For example: * In XML an "object property" can be represented as either an attribute or an element, in JSON only dicts can have attributes. * In XML elements can contain a mix of text and child elements. For serializing objects this is almost never desired. * JSON has a single way to define lists, in XML you need to roll your own.
  - GoblinSlayer 6y ago
    In JSON "object property" is not synonymous to "dict", dict is just one of many ways to express object properties. JSON can contain a mix of differently typed objects too, which is similarly meaningless for serialization. And serialization is not the only usage of json. JSON has a concept of list, but lists can be defined in many ways. And list is not the only collection type one might want to express in json. For example, is package dependency list a list or a dict?

Sander_Marechal 6y ago

That's one way to map that to XML. But there are a dozen other ways to map it as well, and all equally (un)usable.

MaxBarraclough 6y ago

> context-free grammar, the same type of grammars used to specify programming languages As I understand it, few modern programming languages have context-free grammars.

thinkharderdev 6y ago

Of course you can serialize a struct to XML in an idiomatic way but a lot of the time you don't. You get an XML document produced by someone else that maps to a horribly non-idiomatic representation as an object in your language runtime. I have personally seen lists/arrays serialized to XML in a bewildering variety of ways. The advantage of JSON I think is that the mapping to data structures is relatively straightforward and idiomatic so when you are creating a type to represent a JSON document you are receiving from some external source, you are likely to get something that looks reasonable.

Joker_vD 6y ago

But nobody marshals like that (except you, obviously)! Your Person struct is usually marshalled like this: <person> <name></name> <children> <person> <name></name> <children> </children> </person> <person> <name></name> <children> </children> </person> <children> </person> or, if you're unlucky, even like this: <person> <name></name> <person> <name></name> </person> <person> <name></name> </person> </person> with implicit arrays. Not that your scheme is much better, really, why are you putting you favourite language's types in the tags? My favourite one uses lists and binaries instead of vectors and strings, you know.

guiraldelli 6y ago
Thank you for improving it. In fact, I prefer your first example and if I had thought about 30 extra seconds, I probably would have written something similar. > Not that your scheme is much better, really, why are you putting you favourite language's types in the tags? My favourite one uses lists and binaries instead of vectors and strings, you know. Because that was just an example that came up in my mind in less than 10 seconds to make my point. I am glad that people understood my point and even came up with better solutions to make my argument even stronger.
- piaste 6y ago
  > I am glad that people understood my point and even came up with better solutions to make my argument even stronger. Your smugness is unwarranted. You claimed that XML has an obvious, natural mapping to data structures. After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons. Your argument didn't come out in very good shape from that exchange.
  - guiraldelli 6y ago
    > You claimed that XML has an obvious, natural mapping to data structures. That is an (i.e. your) interpretation of what I said. Please re-read my text below, in context. >>> [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language. >> [...] >> A XML file is, by definition, a context-free grammar, the same type of grammars used to specify programming languages. >> [...] >> To me, it is immediate to see the correct data structure in both examples. > After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons. > Your argument didn't come out in very good shape from that exchange. I disagree with you: both understood pretty well my data structures and came up with even clearer notation, making my point that it is a suitable grammar representation for data structures. > Your smugness is unwarranted. Seriously?

kanox 6y ago

You're effectively defining a serialization format using a subset of xml. You can do that with JSON as well, adding "type" properties as required. The problem is that everybody has their own subset of xml for serializing objects, while for json you can load arbitrary json into a straight-forward tree of dicts, lists and literals. If receive arbitrary xml the only way to process it is with xml-specific tools because the object model does not map to any programing language.