Henri's rationale includes a number of unsupported assertions, examples:

1) the document should only document conclusions drawn from normative
statements made elsewhere

2) polyglot guidelines only serves to document the overlap of the two 
serialisations as a convenience for authors who wish to pursue this 
style of document production

A recommendation to use utf-8 is a concrete counter example to both of these claims.

Henri further claims that "The HTML5 specification already normatively defines the conformance criteria for all of the features employed in both serialisations.".  I believe that the conformance criteria specified in that document is incomplete and that the Polyglot document seeks to correct that, and can therefore be considered an extension specification:

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs

... and as such, an extension specifications "MAY prohibit certain otherwise conforming content".

I can understand somebody chosing not to participate or endorse such an effort, but I would very much rather that such individuals not stand in the way of this work.  As long as we have editors interested in pursuing this initiative, I believe that the HTML WG should provide a welcome home for normative recommendations that go beyond what is specified in HTML 5.0.

(In reply to comment #1)
> A recommendation to use utf-8 is a concrete counter example to both of these
> claims.

Failure to pursue other bugs should not be considered to invalidate bugs that are pursued.

> Henri further claims that "The HTML5 specification already normatively
> defines the conformance criteria for all of the features employed in both
> serialisations.".  I believe that the conformance criteria specified in that
> document is incomplete and that the Polyglot document seeks to correct that,
> and can therefore be considered an extension specification:
> 
> http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs

I object to Polyglot Markup being framed as an Extension Specification. If conformance of either the text/html or the application/xhtml+xml is not fully defined, such a lack of detail should be fixed in the upstream WHATWG spec.

(In reply to comment #2)

> I object to Polyglot Markup being framed as an Extension Specification.

Can it be anything *but* an extension spec? Is there anything else that allows it to be published - at all? If it is not an extension spec, then what is it?

> If
> conformance of either the text/html or the application/xhtml+xml is not
> fully defined, such a lack of detail should be fixed in the upstream WHATWG
> spec.

One example of such a (possible) detail is that (at least per Validator.nu), then, for XHTML5, there is no requirement to use <tbody> inside a table. Do you suggest to fix that in the HTML5 spec?

(In reply to comment #3)
> (In reply to comment #2)
> 
> > I object to Polyglot Markup being framed as an Extension Specification.
> 
> Can it be anything *but* an extension spec?

I don’t see why not.

> Is there anything else that allows it to be published - at all?

Unfortunalely, AFAICT, the W3C Process allows a WG to publish pretty much whatever it likes as a Note. For example, the XHTML2 WG used this characteristic of the Process to publish http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/

> If it is not an extension spec, then what is it?

A document recounting the conclusions arising from HTML and XML specs given the constraint that a document be conforming HTML and conforming XHTML with the same DOM except for the representation of the xmlns attribute on the root (that constraint being the *definition* of polyglot).

> > If
> > conformance of either the text/html or the application/xhtml+xml is not
> > fully defined, such a lack of detail should be fixed in the upstream WHATWG
> > spec.
> 
> One example of such a (possible) detail is that (at least per Validator.nu),
> then, for XHTML5, there is no requirement to use <tbody> inside a table. Do
> you suggest to fix that in the HTML5 spec?

No. It’s an intentional feature.

(In reply to comment #4)
> 
> A document recounting the conclusions arising from HTML and XML specs given
> the constraint that a document be conforming HTML and conforming XHTML with
> the same DOM except for the representation of the xmlns attribute on the
> root (that constraint being the *definition* of polyglot).

I encourage those that wish to produce such an informative Note per above to do so, and those that wish to produce a normative profile HTML as a Recommendation do so.

This is precisely why I opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=19925

Thank you for your comments here and in the mail threads. I appreciate the time and effort that you put in this. I do not see, however, substantively new or different information here than in bug 9969 and bug 12725, both of which raise the same issue. 

My response in those instances was this:

After lengthy and careful consideration, I am going to resolve this as won't fix for the following reasons.

"Polyglot Markup: HTML-Compatible XHTML Documents" is a normative specification that defines and prescribes behavior for "polyglot markup," as defined within that specification. However, because there are no consequences to user agents, only to authors (not having the same DOM and not creating content that validates as either HTML5 or XML), I have consciously removed any RFC 2119 language, UNLESS it is required by an original normative specification.

Regarding the other issue in comment 1: as many other specifications do, the polyglot spec relies upon some definitions that come from other normative specifications. When and if the references within the polyglot spec are in error or mis-quote the original spec, a bug should be logged against the polyglot specification to that extent, and as editor, I will make corrections as quickly as possible.

Thank you for your patience and your input.

Eliot

*** This bug has been marked as a duplicate of bug 9969 ***