Am I right that, while we can't have SQLite because there's only 1 implementation, we can have XSLT even though there's only 1--unmaintained--implementation?

▲

foul 6 days ago | parent | next [-]

Nah, libxslt is a spinoff of Expat, at the very least (and mozilla mantains its own xslt library) there's a full implementation by the standard writer called Saxon[0]

[0] https://www.saxonica.com/saxon-c/index.xml

▲

joshkel 6 days ago | parent | prev | next [-]

I assume you're referring to Web SQL? As I understand it, the argument against isn't just "there's only 1 implementation," it's "there's no standard and there's only 1 implementation," so the standard would have to devolve to "whatever that 1 implementation does."

https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

	▲	rasz 6 days ago \| parent \| next [-]
		From what I remember main argument was 'developer aesthetics', and then we got unusable without wrappers nonsensical IndexedDB.
	▲	x0x0 6 days ago \| parent \| prev [-]
		Ignoring, obviously, all parallels to chrome itself...

▲

acdha 6 days ago | parent | prev | next [-]

As others have pointed out there are multiple implementations of XSLT, but I’d also argue that this situation seems like a decent argument in favor of that policy. If everyone is using a single implementation then in practice that implementation is the standard and things like Hyrum’s law become serious considerations.

XSLT is grandfathered in from the early days of the web, and while it’s turned out better than Microsoft exposing random COM interfaces which even Windows developers hated it’s still something of a cautionary example of a feature which never really caught on but browser developers have to support decades later or be willing to break a modest number of sites, some relatively important in particular niches like government information. I think of what happened with WebSQL as a reaction to the maintenance costs of a decade earlier.

▲

simonw 6 days ago | parent | prev | next [-]

Firefox uses TransforMiiX.

Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.

▲

ptx 6 days ago | parent | prev | next [-]

Isn't the situation essentially the opposite? We apparently can't have it in the standard just because Google don't want to maintain the specific implementation they have chosen for their browser.

▲

tannhaeuser 6 days ago | parent | prev | next [-]

That's at least not something you can accuse XLST 1.0 of. Like most parts of the old "XML stack", XLST 1.0 has ample implementations in Xalan/C, Xalan/J, Saxon, libxslt2, MS XML, to name only mainstream ones. And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience.

XSLT 2.x/3.y however, while still a "W3C recommendation", violates (or had violated for the longest time) W3C's own policy of at least two interworking implementations to reach "recommendation" stage, and is authored by the vendor of the single XSLT 2.0/3.0 product, which used to be a problem I pointed out several times. Of course, nobody cares about W3C, Inc. anymore, precisely because of those pay-as-you-go and other self-serving policies among other things.

▲

rleigh 6 days ago | parent | next [-]

And also in QtXmlPatterns (now also retired).

Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.

I initiated its removal to the Apache attic in 2022 in https://marc.info/?l=xalan-c-users&m=165593638018553&w=2 and the vote to do this was in https://marc.info/?t=166514497300001&r=1&w=2&n=20. It has now gone nearly four years without any commits being made.

It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.

▲

praseodym 6 days ago | parent | prev | next [-]

Someone is working on a Rust XPath 3.1 and XSLT 3.0 library: https://github.com/Paligo/xee

▲

pas 6 days ago | parent [-]

there's also xrust

https://gitlab.gnome.org/balls/xrust

	▲	oever 5 days ago \| parent [-]
		And Xust, but it's not been worked on for a while. https://gitlab.gnome.org/vandenoever/xust/

▲

rjsw 6 days ago | parent | prev | next [-]

> And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience.

Not my experience, they all have different ideas of what the current node is at any one point in the execution of a script.

▲

mardifoufs 6 days ago | parent | prev [-]

Wait, so what's the reason for the W3C going against its own policy? Is it okay since it's just a recommendation?

▲

gwd 6 days ago | parent | prev | next [-]

> we can't have SQLite because there's only 1 implementation

Well now there are [1] at least [2] three [3] implementations, right?

[1] sqlite.org

[2] https://github.com/tursodatabase/libsql

[3] https://github.com/tursodatabase/turso

	▲	jmull 6 days ago \| parent [-]
		We actually have three distinct one-of-one libraries. There's no standard, so there's no way to really evaluate how standards-compliant they are. It seems like the idea is for the turoso projects to be compatible with sqlite, but it's not clear exactly what means. As a fork, libsql could be kept reasonably backward compatible with recent versions of sqlite by keeping up with merging changes, and avoiding extending sql in conflicting ways. That seems doable if they keep up with the merges, though mainly because they share very large parts of the implementation, so it's not clear it counts as a separate implementation from a web standards perspective. Turso seems like a reimplementation and has a while to go before it achieves some level of compatibility. It probably needs to be much further along before we can really even evaluate it.

▲

bryanrasmussen 6 days ago | parent | prev [-]

What are you talking about? There are many maintained implementations of XSLT at various levels compliance and versions.

The problem is libxslt is built on top of libxml, and libxml is being used for a bunch of stuff through browsers etc. And that it is a C implementation which most others aren't, actually I say most but not sure if there is a C implementation other than libxslt.