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.
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.
I saw this and went back to the black book to read up, and yeah, type 1s are limited to a certain subset of PS because the font is pre-tokenized.
Interesting I never noticed that before now.
FYI Type 3s were totally widely supported, and supported by everything that supported Type 1s. Type 3s may not have worked with ATM, but I had a huge collection of fonts and never remember seeing a Type 3 font that didn't render correctly. I did have commercial fonts from real foundries, so maybe the ones made by people didn't render.
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.
Which break on tons of sites because they simple can't render them and never will. That bloat isn't really bloat because it is necessary to handle what modern users want it to handle. Browsers aren't going to probably ever "diet" again. They'll only remove insecure features.
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.
