7 ms·

XML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. XHTML was a failure, rejected and ditched. So if it lost data interch

XML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. XHTML was a failure, rejected and ditched. So if it lost data interchange and layout/interface specification... what is XML's relevancy (not counting legacy interaction/systems)?

robin_reala 5y ago
XHTML was ditched on the web, sure, but it survives in ePub.
- vbezhenar 5y ago
 XHTML was not ditched on the web, it's supported by all major browsers, at least for now, and I'm not aware of any plans to deprecate it.
 - krapp 5y ago
 It was ditched on the web because no one on the web is using it. Everyone would rather have sites that fail gracefully on markup errors than crash in the browser.
 - acdha 5y ago
 It was never widely used, however, and in many cases those documents were parsed as HTML because the server was never configured correctly — I believe actual correct usage is well under 1% – so I would not be making any new investments in that direction. The big thing I'd be curious about is what happens when new features are added: do they get added to the XHTML parsers as well or does that become a legacy path drifting behind the main web platform? I believe there were already some issues with Chrome along those lines when they added JS modules, for example.
 - WorldMaker 5y ago
 The XHTML 2.0 "standard" was ditched on the web as no major browsers wanted to support it (and mostly still don't [1]). Also, most browsers today no longer support XHTML 1.x "Strict" modes, the errors they surfaced, and instead just laxly parse all XHTML 1.x with the same parsers they use for "HTML5". (IE11 I believe was the last browser with XHTML "Strict" support and used a proper XML parser and error reporting when parsing XHTML.) [1] Outside of how XHTML 2.0 influenced HTML5's list of "semantic DIVs" the tags like ARTICLE and SECTION that don't have any meaningful semantics in current browsers but are nice when you get bored of surrounding everything in DIV. XHTML 2.0's standard attached actual meanings to those tags and had a lot of specified behavior for how those tags would operate. The only surviving "tag behavior" from XHTML 2.0's plan was DETAILS, I believe. I also believe the exact lists of tags are disjoint and XHTML 2.0 had tags that didn't even make into the official "semantic DIV" bucket, are out of spec in HTML5, but HTML5 browsers will mostly just ignore and fallback to treating unknown tags as fallback DIVs anyway.
 - vbezhenar 5y ago
 Here's example of invalid XHTML file with missing ``: https://vbezhenar.com/test-invalid.xhtml https://vbezhenar.com/test-invalid.xhtml And fixed: https://vbezhenar.com/test-valid.xhtml https://vbezhenar.com/test-valid.xhtml It works in Chrome for me, parsing failed as expected on the invalid file. Also you can't use document.write from JS, so DOM has special treatment for XHTML as well.
- aequitas 5y ago
 Still survives in RSS as well, which seems to be making a comeback.
 - Zardoz84 5y ago
 And RDF, OAI EDM, Dublin core, etc
echelon 5y ago
XHTML focused heavily on making markup semantic and reusable. It was strict so that there would be no mistake in extracting information. It wasn't "harder" than HTML5. Tools could author and validate the documents. Google, who cares deeply about their search moat, did not want easily parsable documents that revealed the wealth of underlying data to machines. It might have made it too easy to mine documents and present search results that answered common factual queries. Also, by forging ahead with landing nonstandard feature after feature in Chrome, they were able to bleed away Firefox market share and bend the web to their will. The only mistake XHTML made was the mime type requirement.
- mhitza 5y ago
 What mime type requirement? Did webservers do this automatically, because I just slapped on the proper doctype when authoring XHTML files.
 - anjbe 5y ago
 During the W3C’s period of… lesser judgment, they hoped to fight the plague of invalid HTML markup that dominated the Web by migrating everybody to XML, which unlike HTML with its extremely generous error handling, simply aborts upon any parse error. For example, Firefox’s “Yellow Screen of Death”: https://commons.wikimedia.org/wiki/File:Yellow_screen_of_death.png https://commons.wikimedia.org/wiki/File:Yellow_screen_of_dea... For this to happen, a webpage has to be served with an XML Content-Type by the server—specifically, application/xhtml+xml. HTML documents are served with a Content-Type of text/html. If you write a page entirely in valid XHTML markup, but serve it with an HTML media type, the browser treats it not as XML, but as invalid HTML, like any other tag soup, and turn it into something approximating what you meant. However, some browsers couldn’t handle application/xhtml+xml, and would simply prompt a download dialog for the page rather than displaying it. Well, one browser did that. You know the one… Internet Explorer. Because support for the new media type wasn’t widespread, the W3C allowed serving XHTML 1.0 pages as text/html as a transitional mechanism. They wouldn’t get any of the “benefits” of XML parsing (like the YSOD), but they’d display in IE. XHTML 1.1 and the stillborn 2.0 were required to be served as application/xhtml+xml, and thus saw only the barest minimum of adoption. As transitional mechanisms are wont to do, XHTML 1.0‐as‐text/html stuck around, W3C’s reputation took a blow, and WHATWG seized the reins, codifying browser practices into what’s now known as HTML5. Incidentally, this is the origin of the space everybody puts within a self‐closing tag. An XML parser would see no difference between “ ” and “ ”, but some tag soup HTML parsers of the time did. The XHTML spec had an appendix dedicated to these compatibility tricks that were solely needed because people were serving pages with the only Content-Type that IE understood. https://www.w3.org/TR/xhtml1/#guidelines https://www.w3.org/TR/xhtml1/#guidelines
inshadows 5y ago
> XML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. Why not? AFAIK it worked well. See SAP and many other products.
- AtlasBarfed 5y ago
  Of course it could be done. It was done... with millions of lines of extra code and complexity. I'd say the immediate thing that comes to mind is that there isn't a one-line-code that would deserialize an XML message to language-universal collections (arrays/lists/vectors, dictionaries/hashmaps/assoc. arrays). The closest was XStream in java-land, which I used heavily before JSON became widespread. Secondly, it doesn't have a natural specifier for THIS IS A LIST. You're guessing or relying on mappers/marshalling to produce such things, while JSON can naturally map from JSON to an object graph without excessive mappers, annotations, etc. Other complaints: The attribute/tag dual-duty was also problematic, confused the entire problem space.
  - inshadows 5y ago
    I agree that handling XML is more complex than handling JSON, but only slightly. Unless you use Java of course, where for some reason, handling XML is always pain in the ass. The complexity of XML features (namespaces and bunch of other standards) is hidden in libraries. And some of those features might be useful, only to be re-implemented in JSON, with same amount of additional complexity in libraries. Just recently I used lxml in Python to parse RSS and it gave me collection like if I used json module. Moreover, I used XPath extensively to pick parts of the XML I was interested in. This would have been more complex with manual traversal. Of course there are Python bindings to jq, but in general the jq language isn't as widespread as XPath. Then there's the slight annoyance of accessing attributes via dedicated getter methods as they're "special" as you mention. But in all, I haven't noticed millions of lines of extra code and complexity.
    - AtlasBarfed 5y ago
      I miss xpath dearly in Json
Telemakhos 5y ago
XML still works fines as a data interchange medium. Podcasts are still a thing, for example. There's tons of XML in use where you don't see it daily, like in Apple's .plist files. Librarians use TEI all the time. It's just in the webdev world that people are using it less. I think two steps could give XML new life: write better documentation and get browser makers to support the latest XSLT. JSON and HTML5 had great people writing inspired, lively guides early on, whereas XML documentation is uniformly bland and soul-killing. XSL has never been graced with a decently written and easily comprehensible introduction. Even if one does manage to grok XSL, the really useful features in XSLT 2 and 3 are excluded from browsers, which only support XSLT 1 like it's still 1999. Whenever one asks why the latest XML-adjacent stuff like XSLT isn't built into browsers, one hears that such processing should be done server-side, which is probably why XML is much more alive outside webdev than inside it.
paulddraper 5y ago
Soooo....RSS is a fantasy?

robin_reala 5y ago

XHTML was ditched on the web, sure, but it survives in ePub.

vbezhenar 5y ago
XHTML was not ditched on the web, it's supported by all major browsers, at least for now, and I'm not aware of any plans to deprecate it.
- krapp 5y ago
 It was ditched on the web because no one on the web is using it. Everyone would rather have sites that fail gracefully on markup errors than crash in the browser.
- acdha 5y ago
 It was never widely used, however, and in many cases those documents were parsed as HTML because the server was never configured correctly — I believe actual correct usage is well under 1% – so I would not be making any new investments in that direction. The big thing I'd be curious about is what happens when new features are added: do they get added to the XHTML parsers as well or does that become a legacy path drifting behind the main web platform? I believe there were already some issues with Chrome along those lines when they added JS modules, for example.
- WorldMaker 5y ago
 The XHTML 2.0 "standard" was ditched on the web as no major browsers wanted to support it (and mostly still don't [1]). Also, most browsers today no longer support XHTML 1.x "Strict" modes, the errors they surfaced, and instead just laxly parse all XHTML 1.x with the same parsers they use for "HTML5". (IE11 I believe was the last browser with XHTML "Strict" support and used a proper XML parser and error reporting when parsing XHTML.) [1] Outside of how XHTML 2.0 influenced HTML5's list of "semantic DIVs" the tags like ARTICLE and SECTION that don't have any meaningful semantics in current browsers but are nice when you get bored of surrounding everything in DIV. XHTML 2.0's standard attached actual meanings to those tags and had a lot of specified behavior for how those tags would operate. The only surviving "tag behavior" from XHTML 2.0's plan was DETAILS, I believe. I also believe the exact lists of tags are disjoint and XHTML 2.0 had tags that didn't even make into the official "semantic DIV" bucket, are out of spec in HTML5, but HTML5 browsers will mostly just ignore and fallback to treating unknown tags as fallback DIVs anyway.
 - vbezhenar 5y ago
 Here's example of invalid XHTML file with missing ``: https://vbezhenar.com/test-invalid.xhtml https://vbezhenar.com/test-invalid.xhtml And fixed: https://vbezhenar.com/test-valid.xhtml https://vbezhenar.com/test-valid.xhtml It works in Chrome for me, parsing failed as expected on the invalid file. Also you can't use document.write from JS, so DOM has special treatment for XHTML as well.
aequitas 5y ago
Still survives in RSS as well, which seems to be making a comeback.
- Zardoz84 5y ago
  And RDF, OAI EDM, Dublin core, etc

echelon 5y ago

XHTML focused heavily on making markup semantic and reusable. It was strict so that there would be no mistake in extracting information. It wasn't "harder" than HTML5. Tools could author and validate the documents. Google, who cares deeply about their search moat, did not want easily parsable documents that revealed the wealth of underlying data to machines. It might have made it too easy to mine documents and present search results that answered common factual queries. Also, by forging ahead with landing nonstandard feature after feature in Chrome, they were able to bleed away Firefox market share and bend the web to their will. The only mistake XHTML made was the mime type requirement.

mhitza 5y ago
What mime type requirement? Did webservers do this automatically, because I just slapped on the proper doctype when authoring XHTML files.
- anjbe 5y ago
 During the W3C’s period of… lesser judgment, they hoped to fight the plague of invalid HTML markup that dominated the Web by migrating everybody to XML, which unlike HTML with its extremely generous error handling, simply aborts upon any parse error. For example, Firefox’s “Yellow Screen of Death”: https://commons.wikimedia.org/wiki/File:Yellow_screen_of_death.png https://commons.wikimedia.org/wiki/File:Yellow_screen_of_dea... For this to happen, a webpage has to be served with an XML Content-Type by the server—specifically, application/xhtml+xml. HTML documents are served with a Content-Type of text/html. If you write a page entirely in valid XHTML markup, but serve it with an HTML media type, the browser treats it not as XML, but as invalid HTML, like any other tag soup, and turn it into something approximating what you meant. However, some browsers couldn’t handle application/xhtml+xml, and would simply prompt a download dialog for the page rather than displaying it. Well, one browser did that. You know the one… Internet Explorer. Because support for the new media type wasn’t widespread, the W3C allowed serving XHTML 1.0 pages as text/html as a transitional mechanism. They wouldn’t get any of the “benefits” of XML parsing (like the YSOD), but they’d display in IE. XHTML 1.1 and the stillborn 2.0 were required to be served as application/xhtml+xml, and thus saw only the barest minimum of adoption. As transitional mechanisms are wont to do, XHTML 1.0‐as‐text/html stuck around, W3C’s reputation took a blow, and WHATWG seized the reins, codifying browser practices into what’s now known as HTML5. Incidentally, this is the origin of the space everybody puts within a self‐closing tag. An XML parser would see no difference between “ ” and “ ”, but some tag soup HTML parsers of the time did. The XHTML spec had an appendix dedicated to these compatibility tricks that were solely needed because people were serving pages with the only Content-Type that IE understood. https://www.w3.org/TR/xhtml1/#guidelines https://www.w3.org/TR/xhtml1/#guidelines

inshadows 5y ago

> XML didn't work as a data interchange. JSON and YAML (and TOML etc etc) beat it handily. Why not? AFAIK it worked well. See SAP and many other products.

AtlasBarfed 5y ago
Of course it could be done. It was done... with millions of lines of extra code and complexity. I'd say the immediate thing that comes to mind is that there isn't a one-line-code that would deserialize an XML message to language-universal collections (arrays/lists/vectors, dictionaries/hashmaps/assoc. arrays). The closest was XStream in java-land, which I used heavily before JSON became widespread. Secondly, it doesn't have a natural specifier for THIS IS A LIST. You're guessing or relying on mappers/marshalling to produce such things, while JSON can naturally map from JSON to an object graph without excessive mappers, annotations, etc. Other complaints: The attribute/tag dual-duty was also problematic, confused the entire problem space.
- inshadows 5y ago
  I agree that handling XML is more complex than handling JSON, but only slightly. Unless you use Java of course, where for some reason, handling XML is always pain in the ass. The complexity of XML features (namespaces and bunch of other standards) is hidden in libraries. And some of those features might be useful, only to be re-implemented in JSON, with same amount of additional complexity in libraries. Just recently I used lxml in Python to parse RSS and it gave me collection like if I used json module. Moreover, I used XPath extensively to pick parts of the XML I was interested in. This would have been more complex with manual traversal. Of course there are Python bindings to jq, but in general the jq language isn't as widespread as XPath. Then there's the slight annoyance of accessing attributes via dedicated getter methods as they're "special" as you mention. But in all, I haven't noticed millions of lines of extra code and complexity.
  - AtlasBarfed 5y ago
    I miss xpath dearly in Json

Telemakhos 5y ago

XML still works fines as a data interchange medium. Podcasts are still a thing, for example. There's tons of XML in use where you don't see it daily, like in Apple's .plist files. Librarians use TEI all the time. It's just in the webdev world that people are using it less. I think two steps could give XML new life: write better documentation and get browser makers to support the latest XSLT. JSON and HTML5 had great people writing inspired, lively guides early on, whereas XML documentation is uniformly bland and soul-killing. XSL has never been graced with a decently written and easily comprehensible introduction. Even if one does manage to grok XSL, the really useful features in XSLT 2 and 3 are excluded from browsers, which only support XSLT 1 like it's still 1999. Whenever one asks why the latest XML-adjacent stuff like XSLT isn't built into browsers, one hears that such processing should be done server-side, which is probably why XML is much more alive outside webdev than inside it.

paulddraper 5y ago

Soooo....RSS is a fantasy?