3 ms·

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

by 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?

by rini17 6y ago

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?