barefootliam

These problems are a large part of why later versions of XSLT were developed.

This is neither correct nor helpful, i think. There are examples of dynamic pages using XSLT, and the purpose is not compression at all.

A very simple one - https://wendellpiez.github.io/XMLjellysandwich/IChing/

You might as well say JavaScript is just a compression format for Web assembly language.

3.0 adds JSON support, maps, arrays, to 2.0 - and many other other changes, including streaming and optimizable recursion with the oddly-named xsl:iterate, but the JSON support is biggest for the in-browser uses.

4.0 will add parse-html() too.

XQuery has a different focus from XSLT. XQuery doesn’t have apply-templates, the document-based implicit dispatch that is so central to XSLT, and it doesn’t have the multiple inheritance possible with overloading templates, but it is stronger in the area of modules, and it assumes (in design) an index, a database.

Programmers tend to prefer XQuery syntax, but note that XPath 3 moves XSLT in that direction too, and XSLT 4 will take it further.

The main strength of XSLT for me is that, together with XML, it enables people who do not consider themselves programmers to do advanced text processing.

0.02% of public Web pages, apparently, have the XSLT processing instruction in them, and a few more invoke XSLT through JavaScript (no-one really knows how many right now).

It’s likely more heavily used inside corporate and governmental firewalls, but that’s much harder to measure.

When i first encountered the early GNOME 1 software back in the very late 1990s, and DV (libml author) was active, i was very surprised when i asked for the public API for a library and was told, look at the header files and the source.

They simply didn’t seem to have a concept of data hiding and encapsulation, or worse, felt it led to evil nasty proprietary hidden code and were better than that.

They were all really nice people, mind you—i met quite a few of them, still know some—and the GNOME project has grown up a lot, but i think that’s where libxml was coming from. Daniel didn’t really expect it to be quite so widely used, though, i’m sure.

I’ve actually considered stepping up to maintain libxslt, but i don’t know enough about building on Windows and don’t have access to non-Linux systems really. Remote access will only go so far on Windows i think, although it’d be OK on Mac.

It might be better to move to one of the Rust XML stacks that are under active development (one more active than the other).

Beowulf was a Type 3 PostScript font, not Type 1, so that it could bypass the font cache and could access random numbers on the LaserWriter PostScript interpreter.

Type 3 fonts don't have hinting in the renderer, and require a full PostScript interpreter, so they have never been widely supported.

It's the default combination for printing, and it's probably also default (i didn't check) e.g. on one-bit e-ink screens.

Here at least, firefox depends on libxml2, which comes from a different package. But, bloated is in the eye of the beholder - there's always Dillo and lynx.

No. XML libraries increase the attack _surface_, but XML itself is passive. There was a famous "billion laughs" attack, but JavaScript was also vulnerable to this, as is any language that lets you concatenate strings. The usual fix is a max size on such strings. There are a couple of other potential vulnerabilities, such as the ability to access the content of any URL, including file://etc/group, but again JavaScript has that too.

MathML is being added to WebKit; an implementation offered for Safari was rejected years ago.

When we invented XML we did not have configuration files as a major use case- although the possibility of ubiquity had been hinted at in a speech by Michael Sperberg-McQueen earlier that year, comparing the potential of SGML to the infrastructure in tunnels beneath the city of Chicago.

There's an XPath from 2016 (3.1) but it didn't have any significant input from browser people - so the primary audience represented were people with large, complex, or multitudinous documents.

There's also microxml, although its traction is limited because of a (relatively minor) backward compatibility issue around whitespace in attribute values.

The use case of people editing small simple documents by hand, documents that did not contain mixed content (rich text if you like, with markup inside running text) wasn't major; in creating XML we did discuss having a syntax that distinguished elements that could contain text directly from those that could only contain other elements, but none of the suggestions were compatible with HTML, of course, or any other existing SGML vocabulary, and all of the proposals (including mine) were ugly and had flaws.

The primary advantages of using XML are

* you can use the XML stack - XPath, XSLT, XQuery, RelaxNG, XML Schema, XForms, EXI, etc etc - on your documents (including conf files)

* people who don't think of themselves as programmers can do sane powerful & useful things - the languages are declarative;

* XML documents can be in the problem domain - elements named after things they represent, not "div" and "span" for example

* you can write a custom grammar-based validation check that both gives some rudimentary QA and also helps to drive syntax-directed editors, hierarchical database schemas and so forth;

* syntax errors are fatal, and there's some redundancy in close tags, which help catch errors that often can't be caught easily by checking the data (e.g. for metadata)

For sure there are things we'd do differently with hindsight, but remember also that XML predates the success of JavaScript and CSS. There are things that would be different in JavaScript and CSS today, too, if done again.

There isn't an alternative, largely i think because XML people come at the problem from the idea that documents are primary, not just artifacts of programs.

I think more about the fact libxml and libxslt are large pieces of code and have had CVEs raised against them (and fixed) in the past. They are still actively maintained.

"The biggest advantage of JSON and YAML" should be put in a context of, "when working as a programmer with config files".

When we designed XML, we were working on things like a million pages of Unix documentation, or the flight manuals for aircraft, or research journal articles, or transcriptions of inscriptions found on fragments of ancient Greek pottery - lots of small similar documents, or very complex documents.

XML lets people who are not primarily programmers do sophisticated text processing and information design without depending on outside resources.

People who complain about XML being brittle are saying they want a system that forgives syntax errors, in the same way that JavaScript... doesn't... or that JAVA... doesn't... or that C... doesn't...or that Python... doesn't.

XML is unbeaten for the things it's good at. It was (still is, often) a problem that people used if in places where it wasn't so good. But that doesn't make it bad - it means you need to understand where it's good and where it isn't.