After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 304921 - Invalid mode attribute content is accepted
Invalid mode attribute content is accepted
Status: RESOLVED FIXED
Product: libxslt
Classification: Platform
Component: general
1.1.14
Other All
: Normal normal
: ---
Assigned To: kbuchcik
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2005-05-20 22:02 UTC by Frans Englich
Modified: 2006-08-10 11:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for version 1.1.15 (1.74 KB, patch)
2005-11-27 12:08 UTC, Bart Martens
none Details | Review

Description Frans Englich 2005-05-20 22:02:36 UTC
Please describe the problem:
  
Hello,  
  
According to for example the Element Syntax Reference of XSL-T, the mode  
attribute of for example apply-templates must be a string of type QName.  
  
The specification for XSLT 2.0 states that content in the mode attribute should  
result in a static error if it is not a valid QName. However, I've not found  
anything in the XSLT 1.0 specification that dictates the same reaction. In  
either case is it in my opinion clear that an invalid QName makes no sense.  
  
Currently, libxslt accepts the following stylesheet:  
  
<?xml version="1.0" encoding="UTF-8" ?>  
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">  
  
        <xsl:variable name="var">somevalue</xsl:variable>  
  
        <xsl:template match="/">  
                <xsl:apply-templates mode="$var"/>  
        </xsl:template>  
  
        <xsl:template mode="somevalue" match="/">  
             mode template. 
        </xsl:template>  
  
</xsl:stylesheet>  
  
The second template is never instantiated, and no compilation error is thrown. 
I can't tell if this is a compliant behavior, but a bug report is easy to 
close.. 
 
 
 
Cheers, 
Frans 
 
  

Steps to reproduce:
 

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Bart Martens 2005-11-27 12:08:21 UTC
Created attachment 55272 [details] [review]
patch for version 1.1.15
Comment 2 kbuchcik 2006-03-31 18:42:30 UTC
You are right, for the attribute "mode" with value "$var" the processor
should report an error concerning the invalid QName value.

XSLT 1.0 defines the attribute "mode" to be a QName [1]:

<xsl:apply-templates
  select = node-set-expression
  mode = qname
  <!-- Content: (xsl:sort | xsl:with-param)* -->
</xsl:apply-templates>

Tested with XSLT processors of Saxon 8.7 and MS .NET:
  both report the error

Note that the given example won't instanciate the second template
even if it contained a <xsl:apply-templates mode="somevalue"/>, since:

"In the absence of a select attribute, the xsl:apply-templates instruction processes all of the children of the current node, including text nodes."

So the apply-templates selects the children of the document-node, thus
the second template, which matches the document-node, won't ever be hit.

[1] http://www.w3.org/TR/xslt#element-syntax-summary
Comment 3 kbuchcik 2006-08-10 11:48:26 UTC
Fixed now in the CVS HEAD, preproc.c, revision 1.62.
Also added QName-validation for other attributes where missing.

Thanks for the report!