Project

Profile

Help

Bug #6600

open

current function wrongly allowed in pattern

Added by Heiko Theißen 5 days ago. Updated about 3 hours ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2024-11-29
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

According to https://www.w3.org/TR/xslt-10/#function-current

It is an error to use the current function in a pattern.

But Saxon-JS 2.7.0 compiles the following XSLT 1.0 stylesheet

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="a[.=current()]"/>
</xsl:stylesheet>

It seems that this pattern is effectively treated like the vacuous condition in a[.=.], but a "Static error in pattern" would be preferable.

Actions #1

Updated by Michael Kay 5 days ago

SaxonJS provides an XSLT 3.0 processor that supports XSLT 1.0 backwards compatibility mode.

The fact that something is an error in 1.0 does not make it an error when running 3.0-in-1.0-compatibility-mode.

The semantics of a[.=current()] are well defined in 3.0 (in fact, in 2.0); as you say, the predicate is vacuous. This would not be the case if you wrote, for example

match="a[../@class=current()/@class]"

which would match any a element having the same @class as its parent. Or for something that it's hard to do without current():

match="a[@class=current()/@class]//b"

which matches any b element that has an ancestor a element with a matching @class attribute. (current() in a pattern always refers to the node you are trying to match)`

Actions #2

Updated by Heiko Theißen about 4 hours ago

Michael Kay wrote in #note-1:

SaxonJS provides an XSLT 3.0 processor that supports XSLT 1.0 backwards compatibility mode.

The fact that something is an error in 1.0 does not make it an error when running 3.0-in-1.0-compatibility-mode.

"Backwards compatibility mode" can also change the interpretation of a non-erroneous XSL 1.0 transformation. Example:

The built-in templates used by SaxonJS in an XSL 1.0 transformation pass on parameters so that

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="/">
    <xsl:apply-templates select="/" mode="a">
      <xsl:with-param name="b">X</xsl:with-param>
    </xsl:apply-templates>
  </xsl:template>
  <xsl:template match="*" mode="a">
    <xsl:param name="b"/>
    <xsl:value-of select="$b"/>
  </xsl:template>
</xsl:stylesheet>

outputs an X (for any source document).

A strict XSLT 1.0 implementation would output nothing, because the built-in template for the root node would invoke the second template without parameter b.

Actions #3

Updated by Michael Kay about 3 hours ago

Yes, that's correct. An XSLT 3.0 processor running in backwards compatibility mode will not always produce the same results as an XSLT 1.0 processor.

This particular change is documented in clause 4 of section J.1.4 of the XSLT 2.0 specification. In this particular case an XSLT 2.0 (or 3.0) processor passes on parameters whether or not the stylesheet version is set to 1.0.

Please register to edit this issue

Also available in: Atom PDF Tracking page