This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. [1] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jan/0004.html [2] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2013Jul/0060.html (minutes)
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.
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.