Project

Profile

Help

Bug #4331

closed

XTSE3051 is not raised

Added by Max Toro over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
-
Start date:
2019-10-02
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

Description

accept-pkg.xsl:

<?xml version="1.0"?>
<xsl:package name="http://localhost/pkg" version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:local="http://localhost/pkg">
  
    <xsl:function name="local:foo" visibility="public">
       <xsl:sequence select="'foo'"/>
    </xsl:function>
 
</xsl:package>

accept.xsl:

<?xml version="1.0"?>
<xsl:stylesheet version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:local="http://localhost/pkg"
    expand-text="yes">
 
    <xsl:use-package name="http://localhost/pkg">
       <xsl:accept component="function" names="local:foo" visibility="private"/>
       <xsl:override>
         <xsl:function name="local:foo">
            <xsl:sequence select="'foo2'"/>
         </xsl:function>
      </xsl:override>
   </xsl:use-package>
 
    <xsl:template name="xsl:initial-template">
       hello {local:foo()}
    </xsl:template>
 
</xsl:stylesheet>

command line:

 .\saxonhe\n\9.9.1.5\bin\Transform.exe -xsl:.\accept.xsl -it -lib:.\accept-pkg.xsl

outputs:

<?xml version="1.0" encoding="UTF-8"?>
       hello foo2
   
Actions #1

Updated by Michael Kay over 4 years ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal
  • Applies to branch trunk added

Yes, this looks like a bug. I've made it into test accept-916 in the W3C test suite.

Actions #2

Updated by Michael Kay over 4 years ago

The problem is that at the stage where we read the list of names in `xsl:accept/@names, we only know the name of the function and not its arity.

In fact the spec doesn't say very much about the case where xsl:accept/@names or xsl:expose/@names uses a NameTest with no arity to refer to a function (or a set of functions with the same name and different arity). It doesn't seem to be prohibited, but at the same time the spec has little to say about what it means. We can certainly interpret it as meaning "all functions with that name", and I don't think anything breaks if we do so, but it's not clear that this is what the spec intended.

Actions #3

Updated by Michael Kay over 4 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.9, trunk added

Added a check for the case where xsl:accept accepts all functions with a given name (regardless of arity) and one of those functions is specified in xsl:override.

Actions #4

Updated by Michael Kay over 4 years ago

  • Status changed from Resolved to In Progress

Reopened, because I've noticed the proposed XSLT 3.0 Erratum XT30.E36, which proposes to interpret the spec as follows:

In 3.5.3.1 Visibility of Components (tenth paragraph):

Replace the text:

The value may be a NamedFunctionRef only in the case of stylesheet functions, and distinguishes functions with the same name and different arity.

With:

The value may be a NamedFunctionRef only in the case of stylesheet functions, and distinguishes functions with the same name and different arity. A NameTestXP30 on its own (that is, with no arity) cannot be used to identify a function.

Actions #5

Updated by Michael Kay about 4 years ago

  • Status changed from In Progress to Resolved

I have changed the code and the tests so xsl:accept and xsl:expose now:

  • Don't allow an arity on the name of a component other than a function (clearly an error in the spec, which we weren't catching)

  • Require an arity on the name of a function (not clearly stated in the spec, resolution proposed in draft erratum E36)

Actions #6

Updated by O'Neil Delpratt about 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.7 added

Patch applied in the 9.9.1.7 maintenance release.

Please register to edit this issue

Also available in: Atom PDF