W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2006

[Bug 3123] What is an 'instruction' to element-available()?

From: <bugzilla@wiggum.w3.org>
Date: Thu, 20 Apr 2006 19:36:39 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1FWexD-0000kk-N5@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3123

           Summary: What is an 'instruction' to element-available()?
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: david_marston@us.ibm.com
         QAContact: public-qt-comments@w3.org


Section 2.4 gives the official definition of an XSLT 'instruction' as those
XSLT elements that appear in sequence constructors. The non-normative Appendix
D marks certain elements as instructions, but the following "subsidiary
elements" are not so marked:
xsl:sort
xsl:when, xsl:otherwise
xsl:matching-substring, xsl:non-matching-substring
xsl:with-param
Though non-normative, this suggests that the WG might intend to restrict the
definition to only those XSLT elements that are allowed as children, not just
descendants, of xsl:template.

The real issue is what element-available() will return when given any of those
element names as an argument. They fit the normative definition, so one would
expect 'true' is the correct answer. I think this is good for future-proofing
XSLT as best we can. While the above elements may not appear to be good fodder
for an element-available() test today, it's hard to predict all possible future
enhancements to XSLT. I see no down side to having element-available() return
true for these. If you agree, then all that is needed is an editorial change in
Appendix D to mark these as instructions, or subsidiary instructions if you are
more comfortable with that.

If you disagree, then the definition needs to be tightened up. While
tightening, it would be good to address the possibility for extension
subsidiary elements. In other words, can xsl:choose, xsl:analyze-string,
xsl:call-template, etc. take extension elements as children? (For that matter,
can xsl:attribute-set, xsl:character-map, or xsl:import-schema tolerate any
foreign-namespaced child elements? If not, what is the static error?)
Received on Thursday, 20 April 2006 19:36:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:11 UTC