This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The serialization spec says in 7.1: The HTML output method MUST NOT output an end-tag for empty elements. For HTML 4.0, the empty elements are area, base, basefont, br, col, frame, hr, img, input, isindex, link, meta and param. So, if the result tree contains <link>some content</link>, how is it to be serialized? I think a more precise statement would be: The HTML output method MUST NOT output an end-tag for an empty element if the element type has an empty content model. For HTML 4.0, the element types that have an empty content model are area, base, basefont, br, col, frame, hr, img, input, isindex, link, meta and param.
Sigh! According to the minutes of the teleconference of 2005-06-23 (Item 4j in this members only URI [1]), the XSL WG discussed this issue and agreed that it should be serialized as <link>some content</link>, and suggests that the wording should be same as for the xhtml output method. However, now that I look at it, section 6 describing the xhtml output method doesn't seem to deal with the issue either, so I'm not sure how using that as a model would have helped. It describes the style of empty element tag to use to serialize an XHTML element whose content model is EMPTY and the style of empty element tag to use to serialize an XHTML element whose content model is not EMPTY, but which has no children, but it doesn't say how to deal with an element that has children but whose content model is EMPTY in XHTML. In addition to Michael's proposed change in comment #0, I suggest the following change to section 6: Change start of the second item in the list from: "Given an XHTML element whose content model is EMPTY, . . . " to: "If an element that has no children is an XHTML element with an EMPTY content model, . . ."
Left out the (members only) URI reference from comment #1: [1] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2005Jun/0019.html
At its teleconference of 2008-02-07,[2] the XSL Working Group approved the proposed changes to the descriptions of the html output method in comment #0 and the xhtml output method in comment #1. [2] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2008Feb/0014.html (Members only)
At joint XQuery/XSL teleconference of 2008-02-26,[3] Liam Quin asked whether the answer would be different if the only child of the element was a whitespace text node (action item A-357-03). In other words, if the value of the indent parameter was "yes", and an element whose content model in HTML or XHTML is EMPTY has a single text node child that consists of only whitespace, could a conforming serializer elide the whitespace and emit only an empty element tag? The descriptions of the indent parameter on the xhtml output method and html output methods[4,5] state that whitespace may be added or removed "so long as it does not change the way that a conforming HTML user agent would render the output." In the case of an element whose content model is empty but that actually has a whitespace text node child, eliding the whitespace might have the effect of preventing the user agent from reporting an error. That can be viewed as a change in the way the user agent would render the output, so it's my belief that such whitespace must not be elided, and that the proposal stands as it is. [3] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2008Feb/0054.html (Members only) [4] http://www.w3.org/TR/xslt-xquery-serialization/#XHTML_INDENT [5] http://www.w3.org/TR/xslt-xquery-serialization/#HTML_INDENT
At its teleconference of 2008-03-13,[6] the XSL WG reaffirmed its acceptance of the response proposed in comment #0 and comment #1, and agreed that there was no additional change required for the case where an element with empty content model has a single child that is a whitespace text node and the indent parameter has a value of "yes". [6] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2008Mar/0015.html
At joint teleconference 360 of the XSL and XQuery working groups on 2008-03-18,[7] the XQuery WG concurred with the decision of the XSL WG. As Michael Kay was present when the XSL WG made its decision, I trust he is satisfied with the response. This will be published as erratum SE.E7. [7] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Mar/0059.html (Members-only link)
Published in "Errata for XSLT 2.0 and XQuery 1.0 Serialization"[1] and PER draft of "XSLT 2.0 and XQuery 1.0 Serialization (Second Edition)."[2] [1] http://www.w3.org/XML/2007/qt-errata/xslt-xquery-serialization-errata.html [2] http://www.w3.org/TR/2009/PER-xslt-xquery-serialization-20090421/