[Bug 22911] New: [XSLT 3.0] Temporary Output State

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22911

            Bug ID: 22911
           Summary: [XSLT 3.0] Temporary Output State
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

Under xsl:result-document the spec states:

<quote>
The instructions in the initial template are evaluated in final output state.
An instruction is evaluated in the same output state as its calling
instruction, except that xsl:variable, xsl:param, xsl:with-param,
xsl:attribute, xsl:comment, xsl:processing-instruction, xsl:namespace,
xsl:value-of, xsl:function, xsl:key, xsl:sort, and xsl:message always evaluate
the instructions in their contained sequence constructor in temporary output
state.
</quote>

This list of instructions has not been revised since 2.0. The most obvious
candidates to add to the list are xsl:assert and xsl:merge-key. xsl:map and
xsl:map-entry might also be considered.

However, I wonder whether the list couldn't be shortened? Why do we allow
xsl:result-document to be executed during evaluation of xsl:element but not
during evaluation of xsl:attribute? I can't think of a defensible reason. 

I would be inclined to reduce the list to xsl:variable, xsl:param,
xsl:with-param, xsl:function, xsl:key, xsl:sort, xsl:merge-key. This basically
catches most places where it's unpredictable whether the instruction will be
executed or not.

(Note: I've discovered that Saxon doesn't enforce the rules as strictly as
described in the spec, though that's not the primary motivation for this bug
report. It's easy to enforce the current restrictions and I was halfway through
doing so when I realised that the rule needed to be re-assessed for 3.0)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 9 August 2013 20:16:59 UTC