8 ms·

Its too little too late. XML tried to do too many things. The web always loves things that are quick and dirty. JSON with all its shortcomings was simple enough

Its too little too late. XML tried to do too many things. The web always loves things that are quick and dirty. JSON with all its shortcomings was simple enough to get going. Couple it with HTTP, you can easily get a web service up and running. I wonder, for what are the use cases today one would prefer XML over JSON/GRPC/GraphQL etc ?

tannhaeuser 5y ago
XML was introduced as a simplified SGML subset to base new versions of HTML (XHTML) and other web vocabularies (SVG, MathML) on, but that failed and HTML5 still continues to use tag inference, shortforms, and other SGML features that didn't make it into XML. It wasn't conceived as a payload format for web services.
- Ygg2 5y ago
 There was a desire to do similar for XML. See XML5 than Anne van Kestren worked on. https://annevankesteren.nl/2007/10/xml5 https://annevankesteren.nl/2007/10/xml5 I wrote a parser for it, but it never got traction. I might have to rewrite it again.
 - skissane 5y ago
 Personally I prefer Tim Bray's XML-SW to Anne van Kestren's XML5: http://www.textuality.com/xml/xmlSW.html http://www.textuality.com/xml/xmlSW.html XML-SW drops the internal DTD subset entirely, including entity declarations; this means it doesn't support named entity references except for the predefined ones (apos, quot, gt, lt, amp). I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them. I'm also not sold on the whole "HTML-style error-recovery" idea in XML5. In my mind, the syntactic strictness of XML is a virtue not a vice. I'd support killing processing instructions as well. They are rarely used, and XML namespaces could be used as a replacement.
 - AlbertoGP 5y ago
 I agree with what you wrote except for processing instructions: I’m using them in an XML tool I’m developing for my own use, and while I could devise ways to encode them in other ways by abusing other syntax such as namespaces or (ugh!) comments, I prefer to have them available, indeed to be used sparingly.
 - Ygg2 5y ago
 > I'm also not sold on the whole "HTML-style error-recovery" Having used and written a parser for a similar recoverable localization language (https://projectfluent.org/ https://projectfluent.org/) I'm sold on it. It makes a lot of things easier. It's kinda like adding trailing comma to lists. It's both boon when writing lists by hand and generating it via code. > I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them. Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit. XML5 had a few big ideas: - Ending DTD - Unquoted XML attribs <elem atr1=value> - Error recovery / arbitrary nesting which is similar to HTML <a></a> // Became <a></a> 
 - skissane 5y ago
 > Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit. I'm just going by what is at https://annevankesteren.nl/2007/10/xml5 https://annevankesteren.nl/2007/10/xml5 which gives the impression that <!ENTITY> declarations are still allowed.
 Ygg2 5y ago
 There was a full specification that had more details. It didn't parse <!ENTITY> and similar declarations but treated it as just a dumb string.
 - tannhaeuser 5y ago
 > DTDs are one of the ugliest thing ... not sold on the whole "HTML-style error-recovery" I think there might be a misconception here. HTML5 does have some ad-hoc rules around script, style, and noscript elements, but the vast majority of tag inference it does is straight from SGML, from which both HTML and XML are derived. Tag inference in SGML is driven by (parent) element content models and per-element tag omission indicators. For example, a minimal HTML doc can look as simple as <title>XYZ</title> body text and SGML and HTML infer omitted tags to arrive at <html> <head> <title>XYZ</title> </head> <body> body text </body> </html> The concept of hierarchically structuring a partially tagged text document, possibly with custom Wiki syntax a la markdown, is pretty fundamental to SGML-style angle-bracket markup, and also required to unambiguously assign an address (path) to every node such that it can be styled using eg CSS. Since it requires declarations or a hard-coded vocabulary, it'd be difficult to remove DTDs/element declarations. SGML is formalized in ISO 8879:1986, and there's absolutely nothing vague or speculative about the kind of tag inference it does. It's just that most people don't seem to know SGML and come up with ad-hoc XML extensions that can't be taken seriously without reference and alignment within the greater SGML context when XML itself is specified as a proper SGML subset. It's interesting that you'd be willing to trade processing instructions for XML namespaces. Most experts, including the article's author, seem to agree that namespaces and XML Schema are the worst XML offenders, taking the just gained simplicity of XML away on the spot.
- TedDoesntTalk 5y ago
 May not have been conceived that way, but it became that. XML Schemas were the End of its simplicity.
vbezhenar 5y ago
I'm using XML for SOAP Web services. They are much easier to use than REST, thanks to code generation. I did not try GRPC though. XML is awesome for configurations: with proper XML Schema and proper editor (I use Jetbrains Idea, but there are other options) you'll get almost full validation, auto-complete for free. I would prefer XML for any markup. JSON have one important advantage over XML without DTD/Schema: it's impossible to express array in XML. Another less important advantage is that there's only one way to stringify graph of arrays/maps into JSON. With XML there's no "official" standard, there are plenty of different ways to write maps, for example. But DTD/Schema solves those shortcomings.
- cunthorpe 5y ago
  Any ML can have schemas and JSON does, I don’t know what you’re talking about. What you describe is all just about support from tools, which JSON has plenty now. The advantage that a ML can have over another is how easy it is to: - parse by the machine - read and edit by humans Also useful but less so: - esoteric features like cyclic dependencies - size
  - Ygg2 5y ago
    Yeah, but Yaml and to some extent JSON tooling just shrivel compared to XML. I had to edit Liquibase configs in YAML and XML. YAML was a fucking nightmare.
    - pydry 5y ago
      XML tooling is fucking horrible. I still get flashbacks to maintaining XSLT sometimes. It was a tool that didnt really need to exist and arguably did more harm than good by being "recommended". I remember very clearly that although XML had tooling for schema validation it was awful and people tended not to get beyond the "DTD vs XSD" debate before giving up on it. Both of them sucked. Then there's XPath. Why XPath? Because if your markup language doesnt map to normal programming data structures you need a band aid to fix it. As for SOAP.... that can die in the fiery pits of hell with XMLSpy.
tester34 5y ago
I believe XML is too complex Also: why the fq order matters
- chopin 5y ago
  I think you can define your schema such that order doesn't matter. And for stream processing large xml files imposed order may come handy to avoid a second pass.
krapp 5y ago
JSON won because Javascript natively supports it, and because once the web assimilated everything, everything else had to support it.
- konart 5y ago
  JSON won because it can be easily processed by a human being
  - chopin 5y ago
    You can't comment in JSON which I don't like (to put it mildly). Any real human readable format should support comments.
    - konart 5y ago
      valid point.
  - speed_spread 5y ago
    That's just a matter of what you've been exposed to. While XML will always be a little more verbose than JSON, a well-designed XML document format can be much easier to read than a poorly defined JSON one. Plus, chances are that good XML also specifies a schema, which can be used by editors and tools to help you make sense of the content and rules governing it. JSON has a few schema mechanisms, but they're not integrated into the standard and thus much less supported by tooling.
- pydry 5y ago
  I'm no web historian but IIRC it actually supported XML first. Calling a backend required an XMLHttpRequest call. JSON could be parsed but by "executing" it (shudder). So, whatever reason JSON won it wasnt that.
  - GoblinSlayer 5y ago
    IIRC execution of JSON was suggested as a parsing method, I thought it was actually a nice hack. What's the point to not reuse the javascript parser which is right there?
deepstack 5y ago
the only thing I can think is have binary data to be part of the document . I guess one can also use base64 string in JSON.
jerf 5y ago
What is XML good at: https://news.ycombinator.com/item?id=11446984 https://news.ycombinator.com/item?id=11446984 The post here for your convenience: "What is XML good at?" (For the purposes of this post, I'm including HTML in the XML family.) XML/HTML is good when: 1. You have two dimensions of markup you want to do. That is, you have a clear distinction between what is a new "tag" and what is an attribute on that tag. If you can't almost instantly decide whether some feature you want to add works as an attribute or a tag, you probably shouldn't be in XML. 2. Almost every tag one way or another contains some text, the third dimension that XML supports. A proliferation of tags that never contain any text is a bad sign. A handful may not be a problem, e.g. "hr" in HTML, but they should be the exception. 3. You have a really good use case for XML namespacing, the fourth dimension of information that XML supports, in which case there's almost no competition for a well-standardized format, as long as you're also using the previous three dimensions. There's sort of this popular myth that XML is useless, which I think isn't because it's true or that XML is bad, I think it's because in general, most times you want to dump out a data structure #1 isn't true, let alone #2 or #3. In a lot of data sets, you've only got the two dimensions of "simple structure" and "text", not annotations on the structure itself. (Or, perhaps even more accurately, they end up implicit in the format itself, and the format is constant enough for that to be just fine.) A lot of stuff in the 1990s and 200xs used XML "because XML" even though it clearly failed #1. XML is really klunky when you don't want that second dimension because the XML APIs generally can't let you ignore it, or they wouldn't actually be XML APIs. On the other hand, when you learn this distinction, you do come across the occasional JSON-based format that clearly really ought to be XML instead. You can embed anything you want into JSON, but when you're manually embedding a second structure dimension into your JSON document, it loses its advantages over XML fast. If you've ever seen any of the various attempts to fully embed HTML into JSON, without leaving any features behind, you can begin to see why XML or XML-esque standards like HTML aren't a bad idea. HTML is much easier to read for humans than HTML-in-JSON-with-no-compromises. And if you've truly got the four-dimensional use case, XML is really quite nice. When you need all the features, suddenly the libraries, completely standardized serialization, and XPath support and such are all actually convenient and surprisingly easy to use, for what you're getting. Some examples: HTML is a generally good idea. SVG is a middling idea; it passes #1 and #3 but fails #2. SOAP and XML-RPC is generally a bad idea; SOAP fails #1 and #2 but sort of uses #3 and XML-RPC fails all three. XMPP I actually think is pretty solid as an XML format (mere network verbosity problems can be solved with an alternate encoding, though admittedly that becomes non-standard), and in a lot of ways, the real problem with XMPP isn't so much the format itself as that people are not used to dealing with the four-dimensional data structures that result. People expecting IRC-esque flat text are not expecting such detail. Using the fourth dimension of namespaces for extensibility is neat, but few developers understand it, or want to.
tragomaskhalos 5y ago
Around 17 years ago I encoded some information in this little-known thing called JSON because it was more succint and generally a better fit than XML for this particular case. Even so, I'd never encountered this JSON thing before and had no idea if it had real legs or not, so it felt vaguely weird to be eschewing the Great God XML in favour of it ...

tannhaeuser 5y ago

XML was introduced as a simplified SGML subset to base new versions of HTML (XHTML) and other web vocabularies (SVG, MathML) on, but that failed and HTML5 still continues to use tag inference, shortforms, and other SGML features that didn't make it into XML. It wasn't conceived as a payload format for web services.

Ygg2 5y ago
There was a desire to do similar for XML. See XML5 than Anne van Kestren worked on. https://annevankesteren.nl/2007/10/xml5 https://annevankesteren.nl/2007/10/xml5 I wrote a parser for it, but it never got traction. I might have to rewrite it again.
- skissane 5y ago
 Personally I prefer Tim Bray's XML-SW to Anne van Kestren's XML5: http://www.textuality.com/xml/xmlSW.html http://www.textuality.com/xml/xmlSW.html XML-SW drops the internal DTD subset entirely, including entity declarations; this means it doesn't support named entity references except for the predefined ones (apos, quot, gt, lt, amp). I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them. I'm also not sold on the whole "HTML-style error-recovery" idea in XML5. In my mind, the syntactic strictness of XML is a virtue not a vice. I'd support killing processing instructions as well. They are rarely used, and XML namespaces could be used as a replacement.
 - AlbertoGP 5y ago
 I agree with what you wrote except for processing instructions: I’m using them in an XML tool I’m developing for my own use, and while I could devise ways to encode them in other ways by abusing other syntax such as namespaces or (ugh!) comments, I prefer to have them available, indeed to be used sparingly.
 - Ygg2 5y ago
 > I'm also not sold on the whole "HTML-style error-recovery" Having used and written a parser for a similar recoverable localization language (https://projectfluent.org/ https://projectfluent.org/) I'm sold on it. It makes a lot of things easier. It's kinda like adding trailing comma to lists. It's both boon when writing lists by hand and generating it via code. > I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them. Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit. XML5 had a few big ideas: - Ending DTD - Unquoted XML attribs <elem atr1=value> - Error recovery / arbitrary nesting which is similar to HTML <a></a> // Became <a></a> 
 - skissane 5y ago
 > Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit. I'm just going by what is at https://annevankesteren.nl/2007/10/xml5 https://annevankesteren.nl/2007/10/xml5 which gives the impression that <!ENTITY> declarations are still allowed.
 - Ygg2 5y ago
 There was a full specification that had more details. It didn't parse <!ENTITY> and similar declarations but treated it as just a dumb string.
 - tannhaeuser 5y ago
 > DTDs are one of the ugliest thing ... not sold on the whole "HTML-style error-recovery" I think there might be a misconception here. HTML5 does have some ad-hoc rules around script, style, and noscript elements, but the vast majority of tag inference it does is straight from SGML, from which both HTML and XML are derived. Tag inference in SGML is driven by (parent) element content models and per-element tag omission indicators. For example, a minimal HTML doc can look as simple as <title>XYZ</title> body text and SGML and HTML infer omitted tags to arrive at <html> <head> <title>XYZ</title> </head> <body> body text </body> </html> The concept of hierarchically structuring a partially tagged text document, possibly with custom Wiki syntax a la markdown, is pretty fundamental to SGML-style angle-bracket markup, and also required to unambiguously assign an address (path) to every node such that it can be styled using eg CSS. Since it requires declarations or a hard-coded vocabulary, it'd be difficult to remove DTDs/element declarations. SGML is formalized in ISO 8879:1986, and there's absolutely nothing vague or speculative about the kind of tag inference it does. It's just that most people don't seem to know SGML and come up with ad-hoc XML extensions that can't be taken seriously without reference and alignment within the greater SGML context when XML itself is specified as a proper SGML subset. It's interesting that you'd be willing to trade processing instructions for XML namespaces. Most experts, including the article's author, seem to agree that namespaces and XML Schema are the worst XML offenders, taking the just gained simplicity of XML away on the spot.
TedDoesntTalk 5y ago
May not have been conceived that way, but it became that. XML Schemas were the End of its simplicity.

vbezhenar 5y ago

I'm using XML for SOAP Web services. They are much easier to use than REST, thanks to code generation. I did not try GRPC though. XML is awesome for configurations: with proper XML Schema and proper editor (I use Jetbrains Idea, but there are other options) you'll get almost full validation, auto-complete for free. I would prefer XML for any markup. JSON have one important advantage over XML without DTD/Schema: it's impossible to express array in XML. Another less important advantage is that there's only one way to stringify graph of arrays/maps into JSON. With XML there's no "official" standard, there are plenty of different ways to write maps, for example. But DTD/Schema solves those shortcomings.

cunthorpe 5y ago
Any ML can have schemas and JSON does, I don’t know what you’re talking about. What you describe is all just about support from tools, which JSON has plenty now. The advantage that a ML can have over another is how easy it is to: - parse by the machine - read and edit by humans Also useful but less so: - esoteric features like cyclic dependencies - size
- Ygg2 5y ago
  Yeah, but Yaml and to some extent JSON tooling just shrivel compared to XML. I had to edit Liquibase configs in YAML and XML. YAML was a fucking nightmare.
  - pydry 5y ago
    XML tooling is fucking horrible. I still get flashbacks to maintaining XSLT sometimes. It was a tool that didnt really need to exist and arguably did more harm than good by being "recommended". I remember very clearly that although XML had tooling for schema validation it was awful and people tended not to get beyond the "DTD vs XSD" debate before giving up on it. Both of them sucked. Then there's XPath. Why XPath? Because if your markup language doesnt map to normal programming data structures you need a band aid to fix it. As for SOAP.... that can die in the fiery pits of hell with XMLSpy.

tester34 5y ago

I believe XML is too complex Also: why the fq order matters

chopin 5y ago
I think you can define your schema such that order doesn't matter. And for stream processing large xml files imposed order may come handy to avoid a second pass.

krapp 5y ago

JSON won because Javascript natively supports it, and because once the web assimilated everything, everything else had to support it.

konart 5y ago
JSON won because it can be easily processed by a human being
- chopin 5y ago
  You can't comment in JSON which I don't like (to put it mildly). Any real human readable format should support comments.
  - konart 5y ago
    valid point.
- speed_spread 5y ago
  That's just a matter of what you've been exposed to. While XML will always be a little more verbose than JSON, a well-designed XML document format can be much easier to read than a poorly defined JSON one. Plus, chances are that good XML also specifies a schema, which can be used by editors and tools to help you make sense of the content and rules governing it. JSON has a few schema mechanisms, but they're not integrated into the standard and thus much less supported by tooling.
pydry 5y ago
I'm no web historian but IIRC it actually supported XML first. Calling a backend required an XMLHttpRequest call. JSON could be parsed but by "executing" it (shudder). So, whatever reason JSON won it wasnt that.
- GoblinSlayer 5y ago
  IIRC execution of JSON was suggested as a parsing method, I thought it was actually a nice hack. What's the point to not reuse the javascript parser which is right there?

deepstack 5y ago

the only thing I can think is have binary data to be part of the document . I guess one can also use base64 string in JSON.

jerf 5y ago

What is XML good at: https://news.ycombinator.com/item?id=11446984 https://news.ycombinator.com/item?id=11446984 The post here for your convenience: "What is XML good at?" (For the purposes of this post, I'm including HTML in the XML family.) XML/HTML is good when: 1. You have two dimensions of markup you want to do. That is, you have a clear distinction between what is a new "tag" and what is an attribute on that tag. If you can't almost instantly decide whether some feature you want to add works as an attribute or a tag, you probably shouldn't be in XML. 2. Almost every tag one way or another contains some text, the third dimension that XML supports. A proliferation of tags that never contain any text is a bad sign. A handful may not be a problem, e.g. "hr" in HTML, but they should be the exception. 3. You have a really good use case for XML namespacing, the fourth dimension of information that XML supports, in which case there's almost no competition for a well-standardized format, as long as you're also using the previous three dimensions. There's sort of this popular myth that XML is useless, which I think isn't because it's true or that XML is bad, I think it's because in general, most times you want to dump out a data structure #1 isn't true, let alone #2 or #3. In a lot of data sets, you've only got the two dimensions of "simple structure" and "text", not annotations on the structure itself. (Or, perhaps even more accurately, they end up implicit in the format itself, and the format is constant enough for that to be just fine.) A lot of stuff in the 1990s and 200xs used XML "because XML" even though it clearly failed #1. XML is really klunky when you don't want that second dimension because the XML APIs generally can't let you ignore it, or they wouldn't actually be XML APIs. On the other hand, when you learn this distinction, you do come across the occasional JSON-based format that clearly really ought to be XML instead. You can embed anything you want into JSON, but when you're manually embedding a second structure dimension into your JSON document, it loses its advantages over XML fast. If you've ever seen any of the various attempts to fully embed HTML into JSON, without leaving any features behind, you can begin to see why XML or XML-esque standards like HTML aren't a bad idea. HTML is much easier to read for humans than HTML-in-JSON-with-no-compromises. And if you've truly got the four-dimensional use case, XML is really quite nice. When you need all the features, suddenly the libraries, completely standardized serialization, and XPath support and such are all actually convenient and surprisingly easy to use, for what you're getting. Some examples: HTML is a generally good idea. SVG is a middling idea; it passes #1 and #3 but fails #2. SOAP and XML-RPC is generally a bad idea; SOAP fails #1 and #2 but sort of uses #3 and XML-RPC fails all three. XMPP I actually think is pretty solid as an XML format (mere network verbosity problems can be solved with an alternate encoding, though admittedly that becomes non-standard), and in a lot of ways, the real problem with XMPP isn't so much the format itself as that people are not used to dealing with the four-dimensional data structures that result. People expecting IRC-esque flat text are not expecting such detail. Using the fourth dimension of namespaces for extensibility is neat, but few developers understand it, or want to.

tragomaskhalos 5y ago

Around 17 years ago I encoded some information in this little-known thing called JSON because it was more succint and generally a better fit than XML for this particular case. Even so, I'd never encountered this JSON thing before and had no idea if it had real legs or not, so it felt vaguely weird to be eschewing the Great God XML in favour of it ...