Thank you for posting this! Now I know that I'm not the only “grumpy
old man” who smells the fishy part of the “Modern Web”.
With that said, I would love the author to go on and elaborate on other
advantages of XHTML2, such as possible integrations with XForms
(including more inputs and sending requests without page reloading and
without JavaScript), XFrames, the single header element <h>, every
element as a hyperlink, etc. Then there are MathML and XSLT. If XHTML2
became a reality, we would probably see XSLT 2.0 more actively adopted
by the browser vendors, which is a good thing in my book.
XForms is one of the things I wish would be more widespread, it’s such a good idea in principle. I think it just gets tarred with the “XML is bad” brush and ignored.
Someone should write an article and call it something like “‘XML
Considered Harmful’ Considered Harmful”. By no means is XML a very nice
one to work with (manually). But at some point during late 1990s it had
a real chance of becoming the document and data mark-up language, with
standards allowing you to do pretty much anything with it. And a bunch
of WYSIWYG tools for those who are allergic to plain text and scriptable
editors. And I think it would be a slightly better world.
I wish the XML community had given proper priority to usability along with quality tooling and examples. There was a solid decade where people would work on a spec which sounded cool but effectively never shipped from the perspective of working developers or did so with enough bugs/inconsistent support/poor performance/bad UX that it was a net cost. As a simple example, you still can’t use XPath 2 portably because libxml2 never implemented it – absolutely nothing that the XML standards community was working on had even 5% of the value that would have come from fixing that or countless similar problems which had a constant pressure to stop using XML. The same was true of good documentation and examples: the assumption was that other people would take time to learn these convoluted specs but most of them started using JSON instead because they could ship so much faster.
> you still can’t use XPath 2 portably because libxml2 never implemented it
That's not the fault of the XML community at large, but just a lack of resources for the implementation of an unpaid open source project.
You can happily use XPath 3.1 with Saxon, BaseX, eXist. All three use Java, so, it's not portable, but Saxon has a C library, that mirrors the Java version 1:1, and that C library is also available as open source, though, it lacks some XPath 3.x features, like higher order functions, then.
For the command line, there is a partial XPath 3.1 implementation with 'xidel'.
But I agree, libxml and libxslt being at XPath 1.0 for so long, did not serve XML well.
I classed that as something for the XML community to prioritize because implementations are so important to adoption for standards. If you design standards and want them to be used, at some point you need to figure out how to get resources to support development of key implementations, help major projects migrate to alternative implementations[1], or develop a replacement if nothing better is available.
The fragmentation you mentioned is part of what made this so frustrating: if everything you used was within certain toolchains, the experience was fairly good but then you'd need to use a different ecosystem and either drop back to good old XPath 1 or take on more technical debt. In many cases, the answer I saw people favor was leaving the XML world as quickly as possible, which is something the community has a strong interest in.
1. For example, Saxon added support for Python just a few days ago: https://www.saxonica.com/saxon-c/release-notes.xml Imagine if that had happened a decade ago and everyone who was stuck with libxml2 could have easily switched?
On a fair note, one should also take into account, that Saxonica is a rather small, even if highly skilled, shop and the program, they create, is a huge undertaking.
The first version of XML was published in february of 1998, I think the chance you're thinking of was somewhere around early 2000s - I'd think 2004 was still possible, at any rate before the apparent failure of SOAP and XSD. By 2006 it was becoming clear it wasn't gonna happen.
JSON is a better data language, but a lot of that can be laid at the feet of XSD and the big squandering of momentum it represented.
I think the problem wast that while XML was an OK mark-up language for human-readable documents, it was horrible as a structured, data interchange language. Unfortunately, that did not prevent people from trying to use XML for data interchange, and this caused widespread hate of it.
XML screwed the pooch by trying to add namespaces after the 1.0 standard was published.
Handling namespaces correctly requires that the parser API be changed in non-backwards-compatible ways. This would have broken every single piece of code that used an XML parser. So instead, people mangled documents by simply flattening all the namespaces together if you tried using the old API.
This was a godawful nightmare and made everybody who was around at the time absolutely hate XML namespaces -- even those of us who know why they are so important. Plus namespaces are not exactly an "ELI5" topic, so a lot of lazy programmers looked at this and said "that's complicated, I don't want to learn it, HEY LOOK there's this older deprecated API that doesn't have them -- I'll use that!" So the old APIs became immortal and in fact gained additional users long after they were deprecated.
They should never have let the 1.0 standard out the door without namespaces in it.
Alternatively, they should have made it more backwards compatible and, most importantly, heavily pressured implementers not to be complete slackers about usability. The cycle I've seen most frequently was something like this:
1. User gets a simple XML file and writes XPath, XSLT, or other code which says `/foo/bar`, which fails.
2. User notices that while it's written as `<foo><bar>` in the source, it's namespaced globally so they change code to use `/ns:foo/ns:bar`, which also fails.
3. User does more reading and realizes it needs to be `/{http://pointless/repetition}foo/{http://pointless/repetition... or something like repeating the document-level namespace definitions on every call so their `ns:foo` is actually translated rather than treated as some random new declaration.
4. User does something hacky with regular expression to get the job done and at the next chance ports everything to JSON instead, seeing 1+ orders of magnitude better performance and code size reductions even though it's technically less correct.
That experience would have been much less frustrating if you could rely on tools implementing the default namespace or being smart enough to allow you to use the same abbreviations present in the document so `<myns:foo>` could be referenced everywhere you cared about it as `myns:foo` with the computer doing the lookup rather than forcing the developer to do it manually.
With that said, I would love the author to go on and elaborate on other advantages of XHTML2, such as possible integrations with XForms (including more inputs and sending requests without page reloading and without JavaScript), XFrames, the single header element <h>, every element as a hyperlink, etc. Then there are MathML and XSLT. If XHTML2 became a reality, we would probably see XSLT 2.0 more actively adopted by the browser vendors, which is a good thing in my book.