Reconsider W3C Recommendation status of XSLT 2.0 and XSLT 3.0

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: "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. 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), 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
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, 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. 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.

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

It's possible that this issue is appropriate for moving to the w3ctag/obsoletion repository to be considered as a request for obsoletion. But it's worth asking first whether there's a currently-chartered working group whose scope includes maintenance of these specifications. (I don't remember what the maintenance arrangements were when the XML Core Working Group was closed.)

First please deal with the factual inaccuracies. There is at least one other widely available product that implements XSLT 3.0, namely Altova RaptorXML. There are several other products that implement XSLT 2.0, for example IBM Websphere and MarkLogic.

Both XSLT 2.0 and 3.0 met the criteria for multiple implementations at the time they were released. Some of these implementations are no longer available, probably because their developers failed to find a business model that would sustain ongoing development and support. I don't believe that there is anything in W3C's processes or charters that suggests a recommendation should be withdrawn simply because one of the implementations has become dominant in the market. The reason for requiring multiple implementations at the time a Recommendation is approved is not to ensure that there is competition in the market, it is to ensure that it is technically possible to produce interoperable implementations, and that has been well demonstrated. The fact that a number of implementors are working to produce new implementations to compete with Saxon emphasises that the standard is alive and well.

As mentioned by the proposer, XSLT 2.0 and 3.0, as standards, have a lot of superstructure that has been built on top of them: schematron is just one example. For many people, the important thing is that multiple implementations could exist, not that they actually do exist: new implementations could be created if they were needed.

The term "wider community" is vague. XSLT 2.0 and 3.0 are very widely used in the publishing community, which is the community that most needed more than XSLT 1.0 was able to offer.

As for the security question, the known vulnerabilities are primarily at the level of XML, not XSLT, and they need to be addressed at that level. Vulnerabilities in XML can't be fixed by removing XSLT from the picture, so they can't logically be cited as justification for doing so. It would certainly be appropriate to ask W3C to reopen the XML Activity in order to address the security issues at the XML level. Also, there is nothing specific to XSLT 2.0 or 3.0 that affects security in a way that is not equally true for XSLT 1.0. In fact, because XSLT 2.0 and 3.0 are mainly used in "back-end" applications, and are rarely used to process untrusted stylesheets, security problems are rarely encountered in real life.

@hannob

@hannob I believe this is the right place to make this request. I believe there's no longer a WG chartered to maintain these Recommendations, and https://www.w3.org/policies/process/#deactivation says the TAG may initiate the process of obsoleting a Recommendation in that case.

[Further process details that aren't directly relevant to the TAG's decision here.] If the TAG agrees that this is the right thing to do, it would then go through an Advisory Committee review. If someone formally objected at that stage (likely, IMO), a W3C Council would be formed to make the final decision. There has been 1 Council so far on the topic of Obsoleting recommendations, whose report is https://www.w3.org/2025/08/vibration2-council-report.html. Unfortunately, the Process was followed badly in that instance, so the Council's decision only addresses the process mistakes rather than creating "case law" that would be useful for this case.

Thanks for chiming in @michaelhkay. I was hoping to ask for your feedback anyway. I'd also like to invite @caribouW3 to give any relevant input before the TAG discusses this next week.

I agree with @michaelhkay's discussion of the reason for requiring independent interoperable implementations in new Recommendations, although my opinion doesn't determine the TAG's overall consensus. He's also right that the Process doesn't describe any consequences when all-but-one implementation are withdrawn. It only describes an Obsolete Recommendation as

An Obsolete Recommendation is a specification that W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded.

I don't see @hannob making an argument that this applies directly. I think we could still recommend Obsoleting a REC if there were a clear process mistake in its publication, and the potential mistake that @hannob is pointing to here is that perhaps the https://www.w3.org/policies/process/#implementation-experience requirement wasn't followed. (Really it's the https://www.w3.org/2017/Process-20170301/#implementation-experience version that's relevant for XSLT 3, but that section hasn't changed much.) This is an intentionally-fuzzy requirement that depends on the Director's/Team's judgement. I also think there should be a high bar to conclude that the AC and Director made a mistake at the time.

The XSLT 2 implementation report is at https://www.w3.org/XML/Group/xslt20-test/Documentation/reportSummary.html and is W3C-member-only. If I'm reading it correctly, it shows 1 complete implementation, 2 mostly-complete implementations, one of which expressed plans to complete the implementation, and 1 less-complete implementation. I believe that's in line with other new Recommendations, although I might be mis-remembering.

The XSLT 3 implementation report is at https://github.com/w3c/xslt30-test/blob/master/report/simpleReportOut.html and rendered at https://rawcdn.githack.com/w3c/xslt30-test/4fc73264fb9ac3dbf3f67413427eccd76f231142/report/simpleReportOut.html. That shows 2 clearly-independent implementations (Exselt and Saxon-9.8) that each pass nearly all of the tests, which again seems in line with other new Recommendations.

So that's the background I'll be bringing into the TAG's discussion of this next week. Please comment here with any other considerations that we should include in our discussion.

Given this important clarification from Michael Kay:

Also, there is nothing specific to XSLT 2.0 or 3.0 that affects security in a way that is not equally true for XSLT 1.0. In fact, because XSLT 2.0 and 3.0 are mainly used in "back-end" applications, and are rarely used to process untrusted stylesheets, security problems are rarely encountered in real life.

…I wonder if, rather than just the question of whether there are any spec obsoletions that would be appropriate, what the TAG might also — or instead — want to consider is:

Should the TAG consider exploring creation of a finding that says something about use of client-side XSLT on the web?

…and I mean, regardless of any particular XSLT version. And by “client-side XSLT on the web”, I mean more precisely: in front-end code that gets executed in web browser engines.

I wonder about that because:

the issue description for this issue alludes to security concerns with XSLT
the issue description of Should we remove XSLT from the web platform? whatwg/html#11523 states:

XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk.
the full abstract for the high-profile security exploits link in that issue description is this:

Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
Michael Kay’s statement (cited at the top of this comment) that “because XSLT 2.0 and 3.0 are mainly used in "back-end" applications, and are rarely used to process untrusted stylesheets, security problems are rarely encountered in real life [on the back-end]” somewhat seems to imply/acknowledge that with client-side XSLT (in front-end code executed in browsers) — in contrast to back-end usage — security problems may in fact be encountered more than just rarely.

And if the TAG does decide it wants to consider all that, then either:

the TAG should also consider moving this issue (back) to an issue tracker that isn’t specifically about spec obsoletion; or
somebody should raise a different issue scoped around the TAG considering whether it needs to first just look into client-side usage of XSLT on the web, and then whether it might eventually want to produce a finding saying something about it

Definitely file a different issue for the question of how the security issues should affect XSLT use.

I'm far from an expert on those, but:

Probably the Security IG should take the first look.
I suspect the key to safe server-side use is that the stylesheet is trusted. My (weak) understanding of XXE vulnerabilities is that they would be more severe on a server than a client.

@simoneonofri

Definitely file a different issue for the question of how the security issues should affect XSLT use.

To be clear, I don’t plan to raise any issue around this anywhere myself.

I'm far from an expert on those

Same here. So my comment was just in the interest of providing suggestions to others who might have more insight or expertise around this — and who have any concerns — about how to focus those (separate from spec-obsoletion discussion).

Probably the Security IG should take the first look.

Yeah, and I guess it’s also worth me pinging @simoneonofri to let him know about this having come up here and elsewhere.

Several categories of security problem have been identified with XSLT in browsers over the past 25 or 30 years.

The first major one was actually an XML one, not XSLT - the billion laughs attack, which also applied to JavaScript, and had a similar fix - any language that allows you to create new string variables by concatenating existing ones can have an exponential memory usage.

Next was that XSLT and XPath allow arbitrary file/URL access, so e.g. XSLT could look for /etc/passwd and send it back to the host, as long as it didn’t contain & or < characters causing the parse to fail :-) JavaScript had this problem too, and in both cases it was easy to resolve - turn off access to local resources for remote sites.

Then there were memory problems or other errors in C coding, e.g. in libxml2, libxslt, or the browser glue. The glue between XPath and JavaScript objects was a likely source of problems, e.g. in IE, but i don't know for sure now.

And yes, you can write XSLT that runs forever. As you can with JavaScript.

The real problems are (1) libxslt maintenance (which should now be moving forward, someone was found, some funding was found, as i understand it), and (2) XSLT and XML address classes of problem that are not generally faced by Web browser developers :-) (but are faced by publishers) and also an unfortunate legacy of animosity.

XSLT 2, XQuery 1, XPath 2, were all made recommendations on the same day, with a HUGE test suite. The W3C process was followed very carefully. There were multiple implementations (around 50 of XQuery as i recall - i was staff contact at the time), and some of these are still around. There are some new ones too, including at least two XSLT implementations in Rust trying to get to XSLT 3. There are quite a few XSLT 2 implementations in use, including one that’s part of the Apache project as well as several in embedded devices (e.g. content-aware network routing), and e.g. Altova. They may offer XSLT 3 now as well. XSLT is indeed used more on servers, and hence is less visible in a browser context, although there are some fairly visible Web sites (e.g. Congress) using XSLT in the browser, as well as RSS feeds and podcast sites, many or which are no longer actively maintained as they simply keep working.

There is very active work on XSLT 4 in a W3C community group. If having a single major implementation means something has to be withdrawn, it’s time to withdraw HTML :-) but it doesn’t mean that. XSLT is very much alive.

The right question architecturally is not, should there be XSLT in the Browser - that’s partly a question about whether it’s OK to break the Web or not. The right question is, if you put XSLT in the browser today, what should it look like? What would be the use cases? It might be worth asking the TAG or even having a workshop around that question, but it would need fleshing out a lot more first.

XSLT is indeed used more on servers, and hence is less visible in a browser context

Just to add to Liam's remark. We don't have comprehensive visibility of what all our users are doing, especially those who use the open-source version of our product, but we do get a sample. We know that it was used by the BBC for handling all their external data feeds during the Olympic Games. We know it's used to publish all the Belgian railway timetables. We know it's used by both the major civilian aircraft manufacturers for managing technical documentation. We know it's used by the US patent office, by several academic publishers, and by the UK government site that publishes all primary and secondary legislation. We discovered by chance the other day (with a bit of detective work) that it seems to be used by our own bank for preparing PDF bank statements. It's used by several of the key players in the rapidly-growing electronic invoicing community in Europe (XRechnung etc). We could go on. For all these people, it's important that XSLT is a public specification and is not under the control of one company.

This all has very little to do with browsers -- but it has a lot to do with the web.

I am very much surprised of that first statement.

I want to mention that I am an Attorney at Law of over a decade, and I did not had the opportunity to have order studies in software, and yet it was XSLT which was my first computer language to study and act upon.

Studying XML

It only required 14 days, 4 hours a day to create a viable project (StreamBurner) in XSLT.

https://git.xmpp-it.net/sch/StreamBurner

XSLT 1.0 is indeed important; and, yet, XSLT 2.0 and 3.0 are more than important, they are crucial.

XSLT as a represenation

As the obvious, misfortunate, and pathetic conspiracy of so called "browser vendors" continues against XML and XSLT in particular, I expect XSLT 1.0 to be forgotten and XSLT 3.0 or, at the very least, XSLT 2.0 to be the common standard.

Not only do I advise to consider the status of XSLT 2.0 and XSLT 3.0 as rcommended standards, I advise to have XSLT as the de facto representation of the whole (X)HTML realm.

Atom, XSLT, and history

With the kind help of NLnet, granting me the opportunity to create an XSLT project, I am currently developing a publication platform which is entirely made of XML, without a shred of HTML code, it is only based on The Atom Syndication Format (RFC 4287), XSL Transformations and also RFC 5005 (Paging and Archiving) in order to enable navigational directives.

https://git.xmpp-it.net/sch/Rivista

Rivista Voyager is exactly as Mr. Robin Cover has described the internet to be. This is a statement of over a couple of decades.

The next version of 'HTML' is expected to be reformulated as an XML application, so that it will be based upon XML rather than upon SGML.

As of December 1998, 'Voyager' was the W3C code name for HTML reformulated as an application of XML.

—Robin Cover (March 02, 2001).

Conclusion

It would be an outrage and an insult to even state of deprecating XSLT 2.0 or XSLT 3.0 in favour of XSLT 1.0 which even the so called "browser vendors" deliiberately fail to implement.

Post script

Speaking of which, it is HTML4 and HTML5 are violating the W3C principles of interoperability and security. They
should not be a "Recommendation" by the W3C. They should be marked as obsolete.

As stated: Atom, XHTML and XSL should be the representation of the FTP, HTTP, and RSYNC realms, and any opinion otherwise is just by a mole which was sent as an agent to those who want to retain the terrible status-quo with the phony "browser war" and other shenanigans.

@michaelhkay

@michaelhkay

I would want to remark your attention, that the incorporation of XML (e.g. The Atom Syndication Format) and XSLT allow for the creation of completely accessible sites, even with audible devices as small as MP3 player without a display screen.

This means, that Atom and XSLT mean for publications that are equally accessible to the blind and deaf, young and old, novice and expert.

XSLT version 2.0 and 3.0 allow to further enable helpful accessibility features that are not possible with XSLT 1.0.

I am sure that you, with experience which exceeds mine - to an extent which I am ashamed to even write that "I" have any "experience" at all - already well aware of that benefit of the incorporation of Atom Documents and XSL Transformations.

@hannob

With respect, attempting to deprecate XSLT 2.0 and 3.0 would be a shameful act against the blind and deaf.

Please. Consider the blind, deaf, and poor people. The internet is not only of the rich.

Also, I suppose that you, as all people here, probably have much more iimportant concerns, so it be fine if you would decide to not further intervene.

Final statement

@michaelhkay

For all these people, it's important that XSLT is a public specification and is not under the control of one company.

We are well aware that centralization is bad, and, as Mr. Lee Gaulman has said in an inteview with Mr. James Delingpole, infiltration is inevitable, and this is probably what has been hapening in W3C in recent years.

Eventually, if XSLT be deprecated, no one will approach to W3C, no one will complain, no one will criticize, and no one will beg.

An alternative organization be formed, and in that organization XSLT 2.0 and 3.0 will not stop for a moment.

Please consider this.
https://blog.saxonica.com/norm/2025/08/20-removing-xslt.html

Respectfully,
Schimon

XSLT will continue to survive, and thrive, even if some insist on depriving developers and people of the many advantages modern XSLT would offer them.

https://blog.saxonica.com/norm/2025/08/20-removing-xslt.html

https://blog.saxonica.com/norm/2025/08/21-styling-xml.html

Please keep comments narrowly focused on whether XSLT 2 and 3 should be marked as Obsolete. Examples of how XSLT 2&3 still have market relevance, as in the case of the NLNet project, are relevant. Attacks on browsers for trying to remove XSLT 1, are not.

FWIW, I expect to argue against obsoleting these RECs, but we need to have the actual TAG discussion next week before we can state a TAG decision on the question.

The real problems are (1) libxslt maintenance (which should now be moving forward, someone was found, some funding was found, as i understand it), and (2) XSLT and XML address classes of problem that are not generally faced by Web browser developers :-) (but are faced by publishers) and also an unfortunate legacy of animosity.

I've stepped in as Gnome's libxslt maintainer, still getting familiar with the code but I have plans to implement XSLT 2 and XSLT 3. There's no funding I'm doing this in the quid pro quo spirit of Free Software and Open Source

The right question architecturally is not, should there be XSLT in the Browser - that’s partly a question about whether it’s OK to break the Web or not. The right question is, if you put XSLT in the browser today, what should it look like? What would be the use cases? It might be worth asking the TAG or even having a workshop around that question, but it would need fleshing out a lot more first.

There are some use cases: some countries like México and the UK use XML and XSLT transformations for their tax processing, having XSLT available on the browser might simplify the development of applications for these tax systems and other applications that serialize their data in XML.

Cheers,
Iván

it is still not clear to me if there exists any full implementation of XSLT 2.0/3.0 beyond Saxon

The only other complete XSLT 3.0 implementation I am aware of is Altova's RaptorXML. I'm aware of at least two projects with XSLT 3.0 implementations under development. Abel Braaksma's Exselt implementation, as you say, is no longer marketed.

XSLT 2.0 is reportedly implemented also in IBM Websphere, MarkLogic, XmlPrime, and Oracle XDK. There have been other implementations, for example one from Intel, that are no longer marketed but might well still be in use.

However, I believe this is all completely irrelevant. It is perfectly normal for the number of implementations of a standard to reduce over time as the market consolidates. There have been times when one company had 90% of the web browser market. The key thing is that the field is open to new entrants.

The issue is processing untrusted XML files with XSLT.

Actually, the issue is with processing untrusted XML files using any technology, period. The same problems occur if you process untrusted XML with Java, Javascript, C#, or XSLT 1.0. So why you cite this as an argument for deprecating XSLT 2.0 and 3.0 is completely beyond me.

The same problems occur if you process untrusted XML with Java, Javascript, C#, or XSLT 1.0. So why you cite this as an argument for deprecating XSLT 2.0 and 3.0 is completely beyond me.

This is incorrect. It is not an issue with Javascript (no direct file access, node.js has, as far as I know, no XML parsing functionality built-in), C# (fixed in 2016, see CVE-2016-3255), or anything parsing XSLT 1.0 with libxslt/libxml2 (fixed in 2013, see CVE-2013-0339), because all of these either were never vulnerable or have recognized that XXE is a serious security vulnerability, and have fixed it.

CORS

The issue is processing untrusted XML files with XSLT.

Actually, the issue is with processing untrusted XML files using any technology, period. The same problems occur if you process untrusted XML with Java, Javascript, C#, or XSLT 1.0. So why you cite this as an argument for deprecating XSLT 2.0 and 3.0 is completely beyond me.

I would want to add, that this should not constitute a problem, as there is this newer mechanism which is called "CORS" to dictate which script or stylesheet to apply and which not; and, obviously, this can be also applied to XSLT stylesheets.

Accessibility

As I initially raised this issue, I learned a few things, but mostly, it has not fundamentally changed the picture for me. I will ignore all the remarks that I feel are unrelated to this issue, e.g., whether XSLT is used at all, or whether it should be supported by browsers.

How could the statement of establishing a publication platform which is designed to be inclusive to an extent which includes even people who are visually impaired, or with hearing loss, or both, be not significantly relevant to the extent that would fundamentally change your opinion?

Fairness

Regarding Michael Kay's remarks above: "In fact, because XSLT 2.0 and 3.0 are mainly used in "back-end" applications, and are rarely used to process untrusted stylesheets, security problems are rarely encountered in real life."

I am objecting to the phrase of "real life". That statement is unfair to state.

In "fair real life", there would not be a few organizations that would try to dictate the (X)HTML experience of others, and by that deprive people from useful technologies, due to conflict-of-interests that those organizations are subjected to, concerning to advertizing, profit and other supposed benefits.

Moreover, those organizations influence others to neglect attention to XPath, a technology which is related to XSLT, and due to that state of affairs, it is easier to work with CSS Selectors than XPath Query with the built-in functions.

Suppression

I have recently published a couple of modules (15 lines each) to facilitate the work with XPath, as easy as with the built-in functions of CSS Selectors.

https://openuserjs.org/discuss/XPath_equivalents_to_querySelector

I am a lawyer, not a specialist as most people here, and I want to ask this.

Why are these couple of modules, which I compiled, not included in the built-in ECMAScript modules set of those internet browsers?

My claim, is that these are indicators, that some people are deliberately and vigorously try to suppress XML, XLink, XSLT, XQuery, XPath and other XML technologies in favour of what we still have today, a malformed XHTML (i.e. HTML) which is patched with ECMAScript in order to compensate the issues of HTML, and to maintain a status-quo.

JavaScript has XMLHttpRequest [1] and fetch [2] that allow you to fetch and parse an XML resource. Those APIs should not be obsoleted because the browser could have security issues parsing that XML when implementing the APIs.

And you can get node.js to fetch and parse XML (e.g. https://blog.logrocket.com/reading-writing-xml-node-js/).

[1] https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

[2] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

This is what my concern here is. By having only one practically usable implementation, and that one implementation has poor security practices and insecure defaults, anyone using these "standards" pushes people towards creating an insecure solution.

This is not a reason for obsoleting a standard.

@hannob

@hannob

I am confused by that statement.

This shows a fundamental misunderstanding of the nature of these security vulnerabilities. The issue is not with "untrusted stylesheets". The issue is processing untrusted XML files with XSLT.

Is there not an issue of processing untrusted HTML files with ECMAScript?

May you please further explain your statement?

@sjehuda

@sjehuda:

@hannob

I am confused by that statement.

Likewise, I am also confused by your statements about CORS, ECMAScript and other things. They seem unrelated to the issue discussed here, and it seems you're thinking about something with browsers.

I already said this, but I will repeat it: This is unrelated to the question of XSLT in browsers. I know there's a heated discussion about that, but it is an entirely unrelated question.

@rhdunn
your linked blogpost about node relies on thirdparty libraries. My point was: node itself contains no XML parsing functionality. However, I'll check those thirdparty libs whether they're vulnerable, and if so, will report it to them.

@hannob

@hannob

Likewise, I am also confused by your statements about CORS, ECMAScript and other things. They seem unrelated to the issue discussed here.

Please. State what is not realizable by my statements, and I will strive to rephrase them.

I write about my productive experiences, and I detail of state of affairs which indicate of various of issues that may well be related to this concern.

I do not mince words, so to speak, and I striive to be as serious as possible.

and it seems you're thinking about something with browsers.

I do not think. I do not speculate. I am not "puzzled", so to say.

Rather, I state the obvious; and I will state this.

I do not "think" of or about "something" with browsers, I blatantly claim of a conspiracy against XSLT and XPath in particular*, and a conspiracy against XML in general.

* Perhaps also other XML technologies which I am not familiar with.

This can not be miscontrued.

Conspiracies are what we, criminal lawyers, and judges, attempt to investigate and research in court.

Nevertheless, I do not think that you have answered to my question, and I still fail to realize your statement, which is.

"This shows a fundamental misunderstanding of the nature of these security vulnerabilities. The issue is not with "untrusted stylesheets". The issue is processing untrusted XML files with XSLT."

And, as for my question.

"Is there not an issue of processing untrusted HTML files with ECMAScript?"

I do not think that it was answered, yet.

It is not a rhetorical question; it is a serious question which meant to challenge your statement, which, as I stated, I think that I still fail to realize.

@michaelhkay

Thank you for all the discussion on this topic over the last 2 weeks. The TAG sees evidence that XSLT 2 and 3 have sufficient market relevance to continue recommending them for implementation, so we are not requesting that the Recommendations be marked as Obsolete.

We're not confident that it would be appropriate to Obsolete a specification because of serious security issues in that specification, if the specification continued to be relevant in the market. Rescinding such a spec would be more appropriate, but this would take a very serious problem. We don't think that security issues in general XML processing rise to either level for the XSLT Recommendations. We haven't evaluated whether the most popular XSLT implementation has "poor security practices", but even if it did, that wouldn't be sufficient to mark XSLT itself as Obsolete.

We're also not confident that it would be appropriate to Obsolete a specification because it was advanced to REC inappropriately. Even if it were appropriate, we see evidence that there was "adequate implementation experience" at the time these specs were advanced, both under the 2004 Process that covered XSLT 2 and the 2017 Process that covered XSLT 3.

When a specification advances to Recommendation, there's some set of implementations that contribute to "adequate implementation experience". There is no requirement that those implementations continue to be publicly available or deployed throughout the life of the Recommendation, or that other implementations replace them if they disappear. As @michaelhkay described, "adequate implementation experience" is to demonstrate that the REC is clear enough to facilitate the creation of new interoperable implementations. Once that's demonstrated, a REC doesn't become less clear just because some implementations disappear.

Fwiw https://developer.chrome.com/docs/web-platform/deprecating-xslt

This is not a Chrome or Chromium-only action: the other two major browser engines also support the removal of XSLT from the web platform: WebKit, Gecko

I take this as evidence in favour of distinguishing 'Web Platform' -oriented RECs from 'World Wide Web' RECs.

The former is concerned heavily with implementability, usability, coherent design, attack surface and technical debt issues. The latter is humanity's planet-wide shared memory. Once deployed, its data formats do not really ever go away, and thoughtful specs need to respect this reality. Many W3C efforts have aspects of both flavour of web standard, but are often closer to one cluster.

XSLT appears for now to be primarily a 'World Wide Web' standard, even if 0.02% of page loads is still a significant number for the parties trying to use those pages. XSLT will also continue chugging away in the background, unseen but enabling many other page views.

I don't want to reopen this github issue, but it is worth trying to come up with a non-polarizing framing for where things like XSLT fit in the web standards landscape, and how W3C handles its ageing XML portfolio.

@imcsk8

@imcsk8 - I've added proposal for this -> https://gitlab.gnome.org/GNOME/libxslt/-/work_items/153#note_2891973 if you're still maintaining it. I'm already writing XPath 3.1 for libxml2 project, and I thought of adding libxslt up to speed as well. See the proposal that I wrote to Nick

Sorry I've been a little slow with libxslt work. I'll check the proposal

Navigation Menu

Repository navigation

Reconsider W3C Recommendation status of XSLT 2.0 and XSLT 3.0 #10

Interoperability

Security

Summary

Studying XML

XSLT as a represenation

Atom, XSLT, and history

Conclusion

Post script

Final statement

18 remaining items

CORS

Accessibility

Fairness

Suppression

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Reconsider W3C Recommendation status of XSLT 2.0 and XSLT 3.0 #10

Description

Interoperability

Security

Summary

Activity

dbaron commented on Oct 27, 2025

michaelhkay commented on Oct 28, 2025

jyasskin commented on Oct 28, 2025

sideshowbarker commented on Oct 29, 2025

jyasskin commented on Oct 29, 2025

sideshowbarker commented on Oct 29, 2025

liamquin commented on Oct 29, 2025

michaelhkay commented on Oct 29, 2025

sjehuda commented on Oct 29, 2025

Studying XML

XSLT as a represenation

Atom, XSLT, and history

Conclusion

Post script

sjehuda commented on Oct 29, 2025

Final statement

jyasskin commented on Oct 29, 2025

sjehuda commented on Oct 29, 2025

imcsk8 commented on Oct 29, 2025

18 remaining items

michaelhkay commented on Nov 11, 2025

hannob commented on Nov 11, 2025

sjehuda commented on Nov 11, 2025

CORS

Accessibility

Fairness

Suppression

rhdunn commented on Nov 11, 2025

bohwaz commented on Nov 11, 2025

sjehuda commented on Nov 11, 2025

hannob commented on Nov 11, 2025

sjehuda commented on Nov 11, 2025

jyasskin commented on Nov 14, 2025

danbri commented on Dec 10, 2025

sjehuda commented on Dec 10, 2025

mutantkeyboard commented on Oct 8, 2026

imcsk8 commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions