W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2017

[Bug 30181] XTDE0040 and backwards compatibility with XSLT 2.0

From: <bugzilla@jessica.w3.org>
Date: Thu, 21 Sep 2017 20:32:15 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30181-523-ldzNzSEAtN@http.www.w3.org/Bugs/Public/>

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I'm not sure there's a problem here. See section 3.5 on packages. There we
explain how an _implicit package_ is transformed into a package:

  <xsl:transform version="3.0" 

    <xsl:namespace-alias stylesheet-prefix="t" result-prefix="xsl"/>

    <xsl:template match="xsl:stylesheet|xsl:transform">
      <t:package declared-modes="no">
        <xsl:copy-of select="@*"/>
        <t:expose component="mode" names="*" visibility="public"/>
        <t:expose component="template" names="*" visibility="public"/>
        <xsl:copy-of select="node()"/>

This transformation shows clearly that all names templates and named modes
become public. Functions do not (but that's ok, since functions where not an
invocation point). 

I think your processor behaves correctly by accepting named templates without a
visibility attribute.

Note that the body of the text of 2.3.4 does not mention that it must be public
(the error in that section does, though). And we say:

   "The effect is analogous to the effect of executing an xsl:call-template 

This is at odds with the error, as call-templates can call private templates
within its scope. Still, I think it make sense that private templates should
not be available for invocation (why otherwise make it private in the top-level

Note also that in 10.1 Named Templates we say:

   "The template name xsl:initial-template is specially recognized in that it 
   provides a default entry point for stylesheet execution"

If we could change it, I think xsl:initial-template, as with int main() in C++
or public static main in Java (https://stackoverflow.com/q/20776413/111575)
should ignore its visibility:

* If we allow it final, and the package is used as library, you'd have a
problem to override it with your own entry point
* If we allow it to be private, we will have the current discussion, though you
could argue that if it's also used as library package, it will then
automatically be hidden
* If we allow it to be abstract, you will only ever receive an error
* If we allow it to be public, it will determine the entry point even if it is
in a library package, which may surprise users (but I don't think we can escape

Hence, it should only ever be public, just like in Java, or we interpret the
above lines in the spec literal and ignore that XTDE0040 forgot to mention an
exception for xsl:initial-template.

BTW: all examples in the spec using xsl:initial-template have a top-level
element of xsl:stylesheet and are therefore implicitly public.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 21 September 2017 20:32:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 21 September 2017 20:32:20 UTC