6 ms·

What's wrong with XML? It's more human-writable than json, more flexible, less quirky than yaml (which I even cannot write without constantly looking into speci

by ungzd 10y ago

What's wrong with XML? It's more human-writable than json, more flexible, less quirky than yaml (which I even cannot write without constantly looking into specification). Binary protocols are not better too, in age of lightbulbs running linux.

nextos 10y ago
I like XMPP but I reckon XML introduced some complexity. For example, many clients (like mcabber) had lots of features broken (e.g. typing notifications) when interacting with GTalk because they couldn't parse XML namespaces properly.
- jerf 10y ago
  If you can't parse XML namespaces at least mostly properly, you can't write an XMPP client. Unfortunately, this disqualifies a lot of the less maintained and/or less well-written parsers. It also sometimes disqualifies "bindings" to things like libxml2, when the bindings are written by someone who doesn't understand namespaces and end up wrecking them even though the underlying library supports them fine. XML namespaces are strange to me. I think they're the simplest example of a standard I consider somewhat simple that to a first approximation nobody understands. It really goes to show that there aren't really all that many people who understand XML qua XML. There's a lot of people who understand "there's angle brackets and attributes and sometimes these entities" and not much more, but there's substantially more meat to correctly understanding XML. Unfortunately (and I mean this fully, not sarcastically or with preaching), to use and implement XMPP requires a somewhat more full understanding of XML than most people have. Namespaces are the biggest sticking point, but XMPP is also a bit quirky in that it tries to have an XML stream, which is sensible enough at the protocol level but often translates strangely up to the API level. (The optimum library for XMPP permits you to use a SAX-like parser for the stream opening, then presents a DOM-like view of each individual element, and there aren't very many libraries that allow both sides of that.)
  - colanderman 10y ago
    The funny thing is, XML namespaces are not that complicated. They're the solution I would come up with given the same task. They're defined simply thus: -- Data model -- 1. Every tag and attribute is optionally namespaced by a URI. (Tags usually are, attributes usually are not.) 2. The meaning of a non-namespaced attribute is defined by the tag to which it's applied. 3. The meaning of a non-namespaced tag is defined by the application. -- Serialization -- 4. To save space in the textual representation of XML, namespaces are (necessarily) referenced by user-defined aliases. 5. To save even more space, a default namespace may be (and usually is) defined for use by tags (but not attributes). 6. Alias definitions live in opening tags, and are scoped to the tag itself and all its children. They are of the form xmlns:{alias}="{namespace}", or xmlns="{namespace}" for the default namespace. 7. Tag and attribute names are prefixed with an alias to indicate that they live in that namespace: {alias}:{tag/attribute name} 8. If a tag name is not prefixed with an alias, it lives in the default namespace (if any). 9. If an attribute name is not prefixed with an alias, it is not namespaced. 10. The aliases generally have no semantic meaning, but there are wacky exceptions (e.g. XML Schema). EDIT, forgot: 11. The "xml" namespace is reserved and predefined as 'http://www.w3.org/XML/1998/namespace' http://www.w3.org/XML/1998/namespace'.
    - jerf 10y ago
      I realized I ought to write it up too, so, I promise you I started before I saw your post :) http://www.jerf.org/iri/post/2950 http://www.jerf.org/iri/post/2950
    - thewonderer 10y ago
      I'm sorry but this list only provides more evidence that XML is too complicated.
      - jerf 10y ago
        First, XML namespaces are an optional add-on, which is definitely not always used. Secondly, when you need namespaces, they're a clean, simple solution to the core problem. When you don't need them, don't use them. Fortunately, unlike some of the DTD stuff which is hard to ignore correctly, it's really easy to not use namespaces. If the complexity comes from the problem, trying to solve it with a too-simple solution is not a virtue. You'll just reinvent the same thing, only worse, and with less library support. For proof... see the endless poorly-supported attempts to do anything even remotely similar for JSON. The good news is that JSON is very simple. The bad news is that when it's too simple, you typically end up with a mess of poorly-designed stuff on top.
TeMPOraL 10y ago
It's definitely not in any way more human-writable than JSON. Nor is it more human-readable. It's a waste of space and coal used to parse it, and it causes unnecessary strain on the eyes of the poor souls that have to read it. SGML derivatives make sense for markup, not structured data representation.
_ZeD_ 10y ago
>>> What's wrong with XML? It's more human-writable than json wait, what?
- mgamache 10y ago
  XML is more readable to people that learned XML first (like me). The younger crowd reads JSON better then XML. Just a matter of perspective. The only argument for XML is that you see the closing tags to know where the element ends. However, I avoid using XML for anything these days.
  - geggam 10y ago
    comments... json needs comments
  - jeremiep 10y ago
    They're not the same. Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Everytime I land in a project using XML I know I'll spend orders of magnitude more time dealing with data than if the project had used YAML or JSON.
    - zeveb 10y ago
      > Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. > XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Of course, your program probably operates on more than just scalars, sequences & maps, which means you still need to convert your JSON structures into application data structures — validating along the way, too.
      - jeremiep 10y ago
        My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! Even working in statically typed languages you can get away with HashMap<String, Object> or IDictionary<string, object> and call it a day. Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in.
legulere 10y ago
It does a good job for markup, but really sucks for data serialisation. You have to come up with a schema, when you can translate your data structures 1:1 into a schema for e.g. json or protocol buffers. With some formats like SVG you even need to parse the document into a DOM and work on it to get things right. Lots of "features" that actually make things just harder to get right. Like XML entities can lead to a billion laughs [1] or sensitive files being included [2]. XML 1.0 files can contain null bytes, 1.1 files can't. [1]: https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs [2]: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...
INTPenis 10y ago
These days you should be following standards, using namespaces, and of course xml libraries. It's not too bad. But it could be much better, that's my point.
jeremiep 10y ago
It looks like you're just way more used to XML than other formats. Not knowing YAML doesn't make XML any less terrible. It took me 10 minutes to learn the YAML format and I find it incredibly more expressive, powerful and readable than XML.
- Mikhail_Edoshin 10y ago
  Have you noticed that YAML specs are noticeably longer than that of XML? (Of XML 1.0, in particular; and that spec describes both the serialization format and a simple grammar description language.)

by ungzd 10y ago

nextos 10y ago

I like XMPP but I reckon XML introduced some complexity. For example, many clients (like mcabber) had lots of features broken (e.g. typing notifications) when interacting with GTalk because they couldn't parse XML namespaces properly.

jerf 10y ago
If you can't parse XML namespaces at least mostly properly, you can't write an XMPP client. Unfortunately, this disqualifies a lot of the less maintained and/or less well-written parsers. It also sometimes disqualifies "bindings" to things like libxml2, when the bindings are written by someone who doesn't understand namespaces and end up wrecking them even though the underlying library supports them fine. XML namespaces are strange to me. I think they're the simplest example of a standard I consider somewhat simple that to a first approximation nobody understands. It really goes to show that there aren't really all that many people who understand XML qua XML. There's a lot of people who understand "there's angle brackets and attributes and sometimes these entities" and not much more, but there's substantially more meat to correctly understanding XML. Unfortunately (and I mean this fully, not sarcastically or with preaching), to use and implement XMPP requires a somewhat more full understanding of XML than most people have. Namespaces are the biggest sticking point, but XMPP is also a bit quirky in that it tries to have an XML stream, which is sensible enough at the protocol level but often translates strangely up to the API level. (The optimum library for XMPP permits you to use a SAX-like parser for the stream opening, then presents a DOM-like view of each individual element, and there aren't very many libraries that allow both sides of that.)
- colanderman 10y ago
  The funny thing is, XML namespaces are not that complicated. They're the solution I would come up with given the same task. They're defined simply thus: -- Data model -- 1. Every tag and attribute is optionally namespaced by a URI. (Tags usually are, attributes usually are not.) 2. The meaning of a non-namespaced attribute is defined by the tag to which it's applied. 3. The meaning of a non-namespaced tag is defined by the application. -- Serialization -- 4. To save space in the textual representation of XML, namespaces are (necessarily) referenced by user-defined aliases. 5. To save even more space, a default namespace may be (and usually is) defined for use by tags (but not attributes). 6. Alias definitions live in opening tags, and are scoped to the tag itself and all its children. They are of the form xmlns:{alias}="{namespace}", or xmlns="{namespace}" for the default namespace. 7. Tag and attribute names are prefixed with an alias to indicate that they live in that namespace: {alias}:{tag/attribute name} 8. If a tag name is not prefixed with an alias, it lives in the default namespace (if any). 9. If an attribute name is not prefixed with an alias, it is not namespaced. 10. The aliases generally have no semantic meaning, but there are wacky exceptions (e.g. XML Schema). EDIT, forgot: 11. The "xml" namespace is reserved and predefined as 'http://www.w3.org/XML/1998/namespace' http://www.w3.org/XML/1998/namespace'.
  - jerf 10y ago
    I realized I ought to write it up too, so, I promise you I started before I saw your post :) http://www.jerf.org/iri/post/2950 http://www.jerf.org/iri/post/2950
  - thewonderer 10y ago
    I'm sorry but this list only provides more evidence that XML is too complicated.
    - jerf 10y ago
      First, XML namespaces are an optional add-on, which is definitely not always used. Secondly, when you need namespaces, they're a clean, simple solution to the core problem. When you don't need them, don't use them. Fortunately, unlike some of the DTD stuff which is hard to ignore correctly, it's really easy to not use namespaces. If the complexity comes from the problem, trying to solve it with a too-simple solution is not a virtue. You'll just reinvent the same thing, only worse, and with less library support. For proof... see the endless poorly-supported attempts to do anything even remotely similar for JSON. The good news is that JSON is very simple. The bad news is that when it's too simple, you typically end up with a mess of poorly-designed stuff on top.

TeMPOraL 10y ago

It's definitely not in any way more human-writable than JSON. Nor is it more human-readable. It's a waste of space and coal used to parse it, and it causes unnecessary strain on the eyes of the poor souls that have to read it. SGML derivatives make sense for markup, not structured data representation.

_ZeD_ 10y ago

>>> What's wrong with XML? It's more human-writable than json wait, what?

mgamache 10y ago
XML is more readable to people that learned XML first (like me). The younger crowd reads JSON better then XML. Just a matter of perspective. The only argument for XML is that you see the closing tags to know where the element ends. However, I avoid using XML for anything these days.
- geggam 10y ago
  comments... json needs comments
- jeremiep 10y ago
  They're not the same. Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Everytime I land in a project using XML I know I'll spend orders of magnitude more time dealing with data than if the project had used YAML or JSON.
  - zeveb 10y ago
    > Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. > XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Of course, your program probably operates on more than just scalars, sequences & maps, which means you still need to convert your JSON structures into application data structures — validating along the way, too.
    - jeremiep 10y ago
      My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! Even working in statically typed languages you can get away with HashMap<String, Object> or IDictionary<string, object> and call it a day. Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in.

legulere 10y ago

It does a good job for markup, but really sucks for data serialisation. You have to come up with a schema, when you can translate your data structures 1:1 into a schema for e.g. json or protocol buffers. With some formats like SVG you even need to parse the document into a DOM and work on it to get things right. Lots of "features" that actually make things just harder to get right. Like XML entities can lead to a billion laughs [1] or sensitive files being included [2]. XML 1.0 files can contain null bytes, 1.1 files can't. [1]: https://en.wikipedia.org/wiki/Billion_laughs https://en.wikipedia.org/wiki/Billion_laughs [2]: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...

INTPenis 10y ago

These days you should be following standards, using namespaces, and of course xml libraries. It's not too bad. But it could be much better, that's my point.

jeremiep 10y ago

It looks like you're just way more used to XML than other formats. Not knowing YAML doesn't make XML any less terrible. It took me 10 minutes to learn the YAML format and I find it incredibly more expressive, powerful and readable than XML.

Mikhail_Edoshin 10y ago
Have you noticed that YAML specs are noticeably longer than that of XML? (Of XML 1.0, in particular; and that spec describes both the serialization format and a simple grammar description language.)