This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When include-content-type is "yes" and a meta element has been added to the head element, should the conditions for stripping out existing meta element differ between HTML and XHTML. If so, why? 6.1.13 XHTML Output Method: the include-content-type Parameter If a meta element has been added to the head element as described above, then any existing meta element child of the head element having an http-equiv attribute with the value "Content-Type", making the comparison without consideration of casing and leading/trailing spaces, MUST be discarded. 7.4.13 HTML Output Method: the include-content-type Parameter "If a meta element has been added to the head element as described above, then any existing meta element child of the head element having an http-equiv attribute with the value "Content-Type" MUST be discarded."
This is a personal response, not on behalf of the XSL and XQuery working groups. In response to a comment on the xhtml output method, the text in section 6.1.13 was amended to mention the effect of case and whitespace in the value of the http-equiv attribute. See [1,2]. It looks like it was an oversight that the same amendment should apply to the html output method. I propose changing the text in section 7.4.13 to be the same as that of 6.1.13. Specifically, in the third paragraph of section 7.4.13, change "the head element having an http-equiv attribute with the value "Content-Type" MUST be discarded," to "the head element having an http-equiv attribute with the value "Content-Type", making the comparison without consideration of case and leading or trailing spaces, MUST be discarded." [1] http://lists.w3.org/Archives/Public/public-qt-comments/2004Nov/0025.html [2] http://lists.w3.org/Archives/Public/public-qt-comments/2005Mar/0058.html
At its teleconference of 2008-03-13,[3] the XSL WG approved the response proposed in comment #1. This now needs the approval of the XQuery WG. [3] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2008Mar/0015.html (Members-only link)
At joint teleconference 360 of the XSL and XQuery working groups on 2008-03-18,[4] the XQuery WG concurred with the decision of the XSL WG. Tim Mills, I trust you will find this response satisfactory. Henry Zongaro, on behalf of the XSL and XQuery working groups [4] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Mar/0059.html (Members-only link)
This will be published as Serialization erratum SE.E5.
Thanks.