(In reply to comment #0)

> These are guidelines, and as such, they should be non-normative
> descriptions referring to the normative requirements in the HTML
> specification itself. If this document is to be published, it
> should instead be on the Note-track.

It should be added that TBL's initially gave this description of what the TAG was looking for:

]] The document should be couched as a specification. It specifies a set of documents, defined by various constraints,  most (though not all, because of the constraints on what scripts do) of which can be checked by a validator.  [[

http://lists.w3.org/Archives/Public/public-html/2010Jun/0225

These suggestions from TAG/TBL are reflected in the name of the document: "Polyglot Markup: HTML-Compatible XHTML Documents".

The word "guideline" doesn't really seem fitting for a document that aims to be very accurate in describing the subset of XML and HTML. A guideline can be deviated from - and you could still be claiming to "be polyglot".  Whereas a specification does not allow such deviation.

There are at least two definitions of "polyglot": parallel syntaxes and shared syntaxes. E.g. "<p></p>" is a shared syntax which both XML and HTML understand. Whereas the use of "xml:lang" and "lang" on the same element, is an example of parallel syntax where the one language more or less ignores the syntax of the other language - what counts is that the net-effect of xml:lang in XML and lang in HTML, is the same.

Henri, who also would like to see the document become a Note, has often applied a very strict defintion of polyglot markup:

]] While I agree that in this case the DOM difference does no harm, relaxing the
goal from "identical" to "compatible" is a definitional slippery slope.[[
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11526#c1

TO WHICH ONE COULD ASK: Making it a note should of course not be interpreted as an invitation to create a document which follows a "definitional slippery slope". But nevertheless: A very strict and accurate definition does lend som support to the specification route.

OTOH: serving a page as polyglot markup does not always lead the author to the goal of having a document that works equally well as XML and as HTML. In a given situation where a document is served as XML to some UAs and HTML to others, it might therefore be beneficial - depending of course on the goals of the author - to add XML-incompatible, browser specific JavaScript (aka HTML5shiv) on the HTML-layer. And if doing such a thing should be seen as a failure to create a polyglot markup, then - clearly, there is one usecase less for polyglot markup.

OTOH, again, for non-XML parsers, one might add conditional comments, so that the page, formally isn't breaking with polyglot markup ...

THEN AGAIN, polyglot markup should of course not be seen as goal in itself. And it could perhaps with some right, be claimed that, if "polyglot markup" represents a specificaiton, then it *does* become more of a goal in itself. 

It could seem as if those who are opposed to Polyglot Markup being a spec are focused on polyglot markup as a strategy for catering for HTML5-incompatible browsers: The idea sought propagated seems to be that Polyglot Markup should not be seen as "the" strategy. Instead HTML5shivs etc are a better strategy. Henri's comment in the Last call poll could be interpreted that way -  see bug 12790. But then again, when polyglot markup discusses javascript, it currently focuses on scripts that work exaclty the same in HTML and in XML, so from that angle it doesn't formally apply.

PRO et CONS:

 * PRO: The spec can be couched as a spec but  *also* as a guideline.  (The principles can be useful even if one does not follow them 100%)
 * PRO: A specification should have better chances of e.g. validator support.
 * CON: Dangerous if the needleye to is so small that no one are able create such a page?

DIFFERENT PURPOSES OF USING POLYGLOT MARKUP. 

We should keep in mind that authors would have different goals of using polyglot markup:

* some are interested in the XML aspect, in itself, for some reason. [To my knowledge, Polyglot Markup represents the first definition of XHTML which doesn't rely on a DTD, which is of interest in  itself - from a XML point of view. Of course, our mileages might vary ...] The view that Polyglot Markup represents XHTML5, is therefore sometimes heard. (Personally, I don't mind if it is perceived that way, as I'm interested in tool support for polyglot markup ...) The XML-aspects of Polyglot Markup are, on the whole, very interesting as it is the first real description of HTML-compatible XML.

* Some are interested in the browser compatibilty aspect - for some reason. (This interest represents a form of XML-focus as well, one could claim, as one then trust the extensibility of XML ).  If the focus is on browser compatibility, then - as always when Web authors create pages, this is a matter of testing what works. If something non-polyglot gives a better result, broadly speaking, then the author will probably follow that path.

* While others might be interested in the "XML tool chain" aspect.  For tool chains, I suspect that round-tripping is important - thus the tool chain use case is interest in a strict definition.

I do NOT believe the Normativity of a specification is necesarily the test of whether it should be on the Recommendation track or not.  The real test for me is if the owning WG plans to maintain the specification or not.

See Section 7.5 "Ending Work on a Technical Report":
http://www.w3.org/2005/10/Process-20051014/process.html#tr-end 

For example the XML Schema Primer is a W3C Recommendation but obviously that specification does not contain normative text. 

See XML Schema Primer 2nd Edition as proof that the XML Schema WG actively maintained this specification:
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/ 

On the other hand the WS-Policy Primer was published as a WG Note since that WG explicitly decided it did NOT want to maintain the specification:
http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/ 

/paulc

mass-move component to LC1

mass-move component to LC1

It would be nice for authors to have a normative document saying if you author your XHTML document in this fashion then browsers will produce a DOM equivalent to the XML version. For the "normative" status to be useful to authors though, browsers would need to get on board.

However, in a larger sense, the difference between normative and guideline documents has been blurred with the HTML WG, as the goal of matching implementations means that the documents are more useful as a way to deal with current implementers' behavior, rather than a recommendation of how this behavior ought to be. 

As far as I can tell, for the HTML WG, normative and guideline documents are functionally equivalent except when describing discouraged but allowable behavior or forward-looking unimplemented behavior.

Thanks for raising this issue. I've heard from a number of people on both sides, and  for reasons similar to that informing the decision around bug 9969 (my response from which I am including here), I am resolving this as won't fix.

From bug 9969:

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 polglot 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

Reopening until the status section and scope discussions complete.

The dependening bugs have been resolved.

I stated that this was to be resolved as WON'T FIX in comment 6 in the body of the bug but errantly resolved it as FIXED. Cleaning that up. Apologies.