Death comes for XSLT
28 points by nytpu
28 points by nytpu
Not responsive to the post, but I have a soft spot in my heart for XSLT.
Back in the very early 2000s I picked up an XSLT wrox book (remember those red behemoths?) written by Michael Kay. He had a section in the book where he connected the early XSLT rules-language to an SGML scheme-based language called DSSSL.
Even thought XSLT was ugly as sin, it had a certain elegance around declarative transformation that I still think should be used in more situations.
Reminds of the wonderful book:
Program Generators with XML and Java by J. Craig Cleaveland (Prentice-Hall, 2001)
I thought it was going to be using XML more along the lines of how SrcML uses it: https://www.srcml.org/about.html
Some Chromium-based browsers have been running a man-in-the-middle attack by injecting propaganda into XSLT websites.
That's not what a man-in-the-middle attack is.
it kinda is, because it injects unintended code into what was supposed to be delivered from website author to the end-user.
XSLT suffered its worst defeat when it became clear that XHTML was not going to be the future of web development.
The whole elegance of it was based on the idea that it you would use an XML -> XML transformation language, and that XML schema validators could make sure that the source and destination schema were obeyed.
Well, in my view XML itself is now a living fossil so I don't see much reason to invest in it. We just learned how to make better languages. It sucks that you can't say what the text content of an XML document is until you download a separate schema file. I think now that we have JSON and parse(jsonDocument) people have forgotten that parse(xmlDocument) isn't even correct. It HAS to be parse(xmlDocument, schema).
So my stance is definitely odd: I'm willing to let the old thing die, but I think we forgot the lessons we should have learned https://xkcd.com/242/
I've built CSTML to restore the vision of a core symmetry between arbitrary documents and "HTML-schematized" documents. It doesn't let schema validation rules influence parser rules, so you can just parse(cstmlDocument).
CSTML also supports schema validation through the "parse don't validate" architecture. Schema valiators are parsers, and anything the parser can consume is considered valid according to that schema.
In theory this could realize the whole vision: users get the ability to have schematized domain-specific documents which are easy for non-technical users to maintain, and then transformations can be written to HTML-schematized CSTML (which looks like this: https://github.com/bablr-lang/bablr-docs/blob/trunk/src/content/docs/guides/cstml.cstml). If a transformation is able to know for sure that its input data follows a known schema, a well-implemented transformation will also be able to guarantee valid output for all possible inputs.
I have mixed feelings because I really like the XML document model. It's a tree of nodes where each node has key-value pairs as attributes and zero or more children. Each child is another node or character data. This is a really nice generic structure that a huge number of things map to.
But the text serialisation of this is pretty horrible. Entities are painful. The way namespaces let you remap names is nice in theory (if two XML document types have a node with the same name, you can use both and disambiguate them with the namespace prefix), but also quite painful for parsing and it would be simpler to either disallow conflicting names in things that import two namespaces, or require that they have identical structure.
The text tree that IGK builds is isomorphic to XML (and generates XML on the back end for processing by other steps), but the input is more or less the same as SILE's LaTeX-inspired syntax. Nodes are defined starting with a backslash then the name, so \foo{} is equivalent to XML's <foo />. Attributes are specified in square brackets, so \foo[key=value]{} or \foo[key="value"]{} are equivalent to XML's <foo key="value" />. Children go in the braces, so \foo{\bar{some} text}} is equivalent to <foo><bar>some</bar> text</foo> but is much easier to type.
It's a shame that the serialisation format and the abstract model were so closely entwined.
I had the same reaction to XSLT: a declarative language for doing tree-to-tree transforms over this document model? Wonderful. That language written as a verbose AST encoded in a verbose markup language? Awful.
Some of the XML-based standards just gave up. SVG throws away XML structure in some places and just has strings that embed something that looks a lot like a PostScript command string (I'm not sure if it actually is PostScript).
If XML had had a better human-editable text serialisation and a standard well-supported, dense binary serialisation then I suspect things would have been much better. gzip-compressed XML is fairly dense, but now you have to chain two (complex, stateful) parsers together when a good binary serialisation could have also improved parsing efficiency.
It's a shame most of the replacements have either a worse abstract model, have a tighter coupling of the abstract model to the serialisation, or both.
XSLT has much more use than viewing styled XML in WWW browser. And XSLT itself still works pretty well. However removing this browser feature is a shameful step.
One of my favorite use-cases for XSLT is that you can attach a stylesheet to a configuration file and user can see nicely formatted config with documentation, notes etc. I have it e.g. in SQL-DK.
I always thought the phone/hope diazo theme engine was fascinating. I think there was a talk where they demoed wrapping a site in BBC.co.uk theme - just using the two sites and diazo rules... But I can't find it now.
https://docs.diazo.org/en/latest/
See also:
Man, between XSLT and what Google is doing to Android they've really been on Evil streak, and that's not even including AI stuff.
XSLT is one of those technologies I've always thought was very cool; my very first website in 2000 was XHTML + XSLT. But I do wonder how we'll feel about this decision in five years. Will this feel like Google Reader, missed a decade later; or like Flash, broadly considered a good removal from the web?
That was not a unilateral decision mind you, Google said “jump” and other browser vendors said “how high?”
I’m baffled by this portrayal. As linked, it genuinely isn’t just Google: Mozilla and Apple are well-documented as having wanted to kill XSLT for some years, they just lacked the enthusiasm to push it. The closest I can get to this portrayal is that once Google said they were going to try again at killing it (they tried before in I think 2013 and gave up), the others said “great, we’ll see how they go with it and gladly remove our own if it’s going okay for them”.
But what Google specifically have done through the process is lied blatantly. They’ve kept on listing security as their primary reason for removing it, even though they made a near-perfect security-issue-free drop-in replacement before they were even willing to call it deprecated. I suspect it might genuinely have been easier to just ship that extension with the browser, freezing the code in a way that means it never needs any maintenance ever again.
(I have been increasingly anti-Google for more than a decade, but I think the strength of some’s focus on Google in the XSLT matter is at least a little misguided. I get the sense that one of the other browser makers might have initiated it before many more years if Google hadn’t.)
So... How many real xslt-based web pages are there that are going to be broken by this decision? I mean, I guess the one that was deliberately created to protest this decision does not count.
“contact the maintainer of the site” — you broke the web Google, own it at least.
I'm not really sure what the criticism here is though. Google informing users of the website to contain the maintainers of the site to me seems to be the sensible action here. It's not unlikely that users of those old sites might be more active than the people that created them, and that is a reasonable mechanism by which to make that transition possible.
Google is the root cause here.
But contacting Google won't fix the website; it won't even be read by a human. The only actionable advice for a user who wants the content to continue to be available is to contact the site maintainer. This doesn't absolve Google, but I don't see any other message being useful.
The only actionable advice for a user who wants the content to continue to be available is to…
switch to another browser.
(I know, it is fragmented and difficult, but whole web ecosystem controlled by a single corporation (Mozilla is just their puppet, well paid) is extremely unhealthy and dangerous)
switch to another browser.
Which browser would you recommend that is continuing to support XSLT? Is it available on iPhones? Does your bank support it? You have to meet your users where they're at.
It's like this - Google is breaking something, and by injecting this warning, they're making it other peoples problem.
By having the message say "contact the maintainer of this site", the user is led to believe that it's the site maintainer's fault for the breakage, when in fact, it is Google's fault.
Meh, I think the wording is pretty neutral.
This site uses XSLT; that functionality is being removed from this browser very soon. When that happens, this page will likely no longer display correctly. You might be able to install a browser extension that allows you to continue viewing it. Otherwise, you should contact the maintainer of the site for further information.
The breakage will occur because the functionality is being removed from this browser. This message offers a potential workaround you can try ahead of time, and if that doesn't work, then contacting the maintainer of the site is a sensible option. Maybe they can direct you to a better browser.
If you're nitpicky, then maybe the first sentence should be written in active voice - "Google is removing that functionality from this browser very soon" - but I think the current phrasing is more natural.