[w3ctag/design-reviews] Reconsider W3C Recommendation status of XSLT 2.0 and XSLT 3.0 (Issue #1163)

hannob created an issue (w3ctag/design-reviews#1163)

I would like to raise an issue with XSLT 2.0 and XSLT 3.0. These have the status of a
"W3C Recommendation": https://www.w3.org/TR/xslt20/ https://www.w3.org/TR/xslt-30/

(I am not very familiar with W3C processes, and I hope this is a good place to raise an
issue like this. If not, feel free to redirect it to the appropriate place.)

XSLT 2.0 and 3.0 are not "standards" in any meaningful sense of the word. The [W3C web
page states](https://www.w3.org/standards/): "W3C web standards are optimized for
interoperability, security, privacy, web accessibility, and internationalization." I
believe XSLT 2.0 and 3.0 violate the first two of those principles.

### Interoperability

The XSLT specification has three major versions. While XSLT 1.0 is supported by multiple
implementations, the same is not true for the later versions. Both XSLT 2.0 and 3.0 are
only supported by a single implementation named Saxon. The specifications have been
written by a member of the company providing this implementation.

XSLT 2.0 gained the status of a [W3C recommendation in 2007](
https://www.w3.org/TR/2007/REC-xslt20-20070123/). 18 years later, it is fair to say that
it has not been accepted and adopted by the wider community.

The XSLT 2.0 specification contains a link to an implementation report that is not
publicly available (which I consider a worrying sign of intransparency). The report
appears to have been created in 2006. It reports about 4 implementations, of which three
are incomplete. Apart from Saxon, it tested IBM's XSLT processor (I do not know if this
is still available), Gestalt (an implementation in the Eiffel programming language that
has [not been updated since 2008](
https://sourceforge.net/projects/gestalt/files/gestalt/1.0/)), and an anonymous
implementation. This report, therefore, supports the impression that there is no usable
and complete implementation of XSLT 2.0 or above except Saxon. It is noteworthy that the
report was likely created before XSLT 2.0 gained "Recommendation" status.

There are two more recent projects that intend to implement XSLT 3.0 in Rust, xee and
xrust, but they are both in early stages and also incomplete.

Worries that XSLT 2.0 would not be widely implemented were already present before it
became a recommendation. I found [a comment from 2005](
https://www.snee.com/bobdc.blog/2005/12/no-plans-in-place-to-upgrade-x.html#comment-15)
indicating that XSLT 2.0 will likely be "a single implementation language".

It is obvious that a specification that is not widely implemented is not interoperable.

According to the [W3C wiki](https://www.w3.org/wiki/Interoperable), the W3C process
"requires multiple implementations". It also defines this as a "success" criterium: "Two
or more independent implementations for each feature, passing the test suite, and
interoperating with each other." According to these statements, XSLT 2.0 and 3.0 do not
fulfill the requirements.

### Security

By only being supported by a single implementation, any technology built on top of XSLT
2.0 and 3.0 pushes its users towards that single implementation. (This is not a
hypothetical example. Recent versions of Schematron are based on XSLT 2.0 and 3.0, and
those have been used in EU standards.)

It is well known that XML parsing is prone to various security issues, most notably XXE
(XML eXternal Entity injection), a class of vulnerabilities that often causes
high-severity security issues by allowing remote file exfiltration.

The behavior of XML implementations and APIs regarding XXE differs substantially. Some
implementations disallow external entities by default (making them secure-by-default,
e.g., Python), others disable entity processing by default, but are vulnerable as soon
as one enables it, and some implementations are simply vulnerable-by-default.

Saxon (and also Java itself) is vulnerable-by-default. This has been [raised in Saxon's
bug tracker](https://saxonica.plan.io/issues/4234). I would summarize the response as
"distracting from the issue". I also personally communicated this issue to Saxon more
recently. They have confirmed to me that they have no plans to change this behavior.

Any use of Saxon that processes XML from untrusted sources is, by default, vulnerable to
XXE attacks. One needs to set extra options to avoid this, and it is not easy to find
this information. Most users of Saxon will probably be unaware of this. I have not found
any mention of XXE in the documentation. (I believe one can avoid those attacks by
setting the 'http://saxon.sf.net/feature/allowedProtocols' property to an empty string.
I have only tested this with Saxon's Python bindings.)

I think it is fair to say that the "Recommendation" status of XSLT 2.0 and 3.0 is
exposing users to unnecessary security risks.

(It is unfortunate to begin with that these security issues have been insufficiently
addressed in the wider XML ecosystem. To my knowledge, no specification exists that
gives recommendations on how implementations should deal with those and other security
problems.)

### Summary

XSLT 2.0 and 3.0 are violating the W3C principles of interoperability and security. They
should not be a "Recommendation" by the W3C. They should be marked as [obsolete](
https://www.w3.org/guide/process/obsolete-rescinded-supserseded.html#obsolete).

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1163


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1163
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1163@github.com>