This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24378 - [XSLT30] xsl:on-empty on more instructions
Summary: [XSLT30] xsl:on-empty on more instructions
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2014-01-23 22:56 UTC by Abel Braaksma
Modified: 2014-07-27 19:08 UTC (History)
1 user (show)

See Also:


Description Abel Braaksma 2014-01-23 22:56:07 UTC
This was briefly mentioned in [1] and discussed earlier at the July 11, 2013 telcon [2]. The idea was to extend xsl:on-empty at least to all node-construction instructions for reasons of usability and orthogonality. 

Other conclusions from that mail:

(a) the expression in the on-empty attribute must be type-consistent with the instruction it appears on. For example, on an LRE the on-empty expression must return an element or nothing.

(b) specifically on xsl:copy, the condition should be based on the emptyness of the constructed element/document, not the emptiness of the selected element/document

This is also relevant to related bugs bug-24142 and bug-24140.

[2] (minutes)
Comment 1 C. M. Sperberg-McQueen 2014-02-10 16:25:57 UTC
We discussed this issue at the Prague face to face.

On consideration, our inclination was not to extend on-empty to further elements, but indeed to cut it back from some places which allow it now.

The current semantics of on-empty for xsl:copy make it mean different things in different cases, which is confusing to some WG members and potentially problematic for implementors.

We discussed a proposal to allow on-empty only in cases where the node being constructed can have children (is an element or a document node).  One WG member found the semantics on xsl:copy confusing enough that he wanted to eliminate it there and allow it only on literal result elements, xsl:element, and xsl:document (etc.)

We didn't feel we had a strong enough consensus to make a binding decision at the moment, though, given that the spec is in Last Call.  We may wish to come back to this on another day, earlier in the day.
Comment 2 Michael Kay 2014-07-27 19:07:55 UTC
On 24 July 2014 the WG decided that the [xsl:]on-empty attribute should apply only to literal result elements, xsl:element, and xsl:copy, and that in the case of xsl:copy it should apply only when the node being copied is an element node.

The reasons for this are that (a) the major use cases for on-empty are concerned with construction of element nodes; (b) the concept of "emptiness" for elements and for nodes such as attributes is quite different, and overloading the concept gets messy, especially in the case of xsl:copy where the different meanings are mixed in one instruction.