W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2014

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 05 Nov 2014 21:06:47 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27189-523-z2et3gL9Gp@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27189

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
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.
Received on Wednesday, 5 November 2014 21:06:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:59 UTC