[Bug 27189] New: [XSLT30] xsl:copy on-empty and document nodes ambiguities

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 27189] New: [XSLT30] xsl:copy on-empty and document nodes ambiguities

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27189

            Bug ID: 27189
           Summary: [XSLT30] xsl:copy on-empty and document nodes
                    ambiguities
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

The spec says two things in 11.9.1.1:

(1) "If the selected item is not an element node, the attribute has no effect,
except that static errors must be reported and type errors may be reported."

(2) "If the result of the instruction in the absence of the on-empty attribute
would be an element or document node ...."

While I think it is possible to create a document node inside xsl:copy, it
would be a document-node as a child of a copied element node, which would be
ignored and it won't change the item type.

There are two ways to solve this ambiguity:
1) remove the reference to document nodes in quote (2)
2) allow document node creation and allow the on-empty type to be document-node

The second solution has the preference (see mail 0057.html below), but if we
allow that, we also need to make sure that the type of on-empty is the same as
the type of the selected item.

This bug is created as a result of WG email discussion, see
- https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Oct/0056.html (member
only)
- https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Oct/0057.html (member
only)

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 27189] [XSLT30] xsl:copy on-empty and document nodes ambiguities

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27189

--- Comment #1 from Abel Braaksma <[hidden email]> ---
As a self-reminder, after this bug is resolved, review rev #765 in the XT3
repository, 2014-10-29 (commit comment refers to this bug number and bug
24049).

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 27189] [XSLT30] xsl:copy on-empty and document nodes ambiguities

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27189

--- Comment #2 from Abel Braaksma <[hidden email]> ---
We should also consider the following scenario, when solving this:

<xsl:copy select="(document-node(root) | somechild)[1]"
    on-empty="my:create-element()">
    <xsl:apply-templates />
</xsl:copy>


This instruction creates either an empty element or empty document. If it
creates an empty document, the on-empty creates the wrong type to replace this.
Should we, in this case, allow the implicit creation of the document node?

Also, semantically, @on-empty is very vague: many of my attempts assumed that
it fires when the selection is empty, but in fact, it fires when the resulting
sequence constructor returns emptiness.

I believe we should make this very, very clear, or rename to something like
"on-empty-content", or even (rigorous, I know), an instruction <xsl:on-empty
select="'foo'">...</xsl:on-empty>, which would be more universally applicable
and less complex in rules. More importantly, it is semantically clearer (at
least imho) and does not suffer from the type-safety rules.

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

Loading...