SUMMARY:  

a) describe how Polyglot Markup can on the WWW: content negotation etc 
    (currently only "XML tool chains" are listed as a use case)
b) describe alternatives to using Polyglot Markup on the WWW:
     use of "modernizing" javascript libraries, browser specific markuip via
     conditional commments etc.

BACKGROUND:

Henri made this comment in his no vote in the Last Call poll:

]] I think publishing this document on the REC track sends the message that the W3C encourages Web authors to use polyglot markup and I think such implied encouragement would be bad due to the cost/benefit characteristics of using polyglot markup to solve problems compared to alternative solutions that have been identified. [[

http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results#xq6

(1) Henri's "alternative solutions" remains to be identified. But the document SHOULD point to alternative strategies.  Currently, Polyglot Markup only describes when it is a useful choice, and says nothing about other ways to the same goal. Which leads me to another point:

(2) The only use case mentioned by the document is "XML tool chains". The document has so far not mentioned, as a use case, that polyglot markup might be used when it is useful to serve XML to some user agents (due to the native exensibility featurs of XML) and HTML to others. For instance, this is how Sam Ruby uses polyglot markup in his blog, AFAICT.  Thus, together with this strategy also belongs HTTP content negotiation: that some UAs get XML while others get HTML. And as well: to this strategy also belongs the fact that some legacy user agents "sniff" the .html extension as "text/html" even when the HTTP header tells that it is XML.

I say this because I suspect that one of Henri's points is that another strategy, rather than polyglot markup, is to use some kind of javascript library to handle the less-capable user agents - instead of using XML-plus-content negotiation. But before Henri's (possible) point make any sense to discuss, the draft itself should not only list "XML tool chains" as the sole incentitive to use Polyglot Markup, but should also list WWW use cases for Polyglot Markup.

(3) An important "philosophical" problem arises when if a "HTML5 shiv" javascript is added to a polyglot document: Can such a document be classified as a "polyglot markup" document when it makes use of scripts which would not have worked in XML? THe word "poly", btw, means "multi". Specifically, it does not mean "duo" or "bi". Thus "polyglot" does not mean "biglot". I would say that a non-XML compatible javascript could be added to a polyglot document.

QUESTIONS (relating to (3)): 
* Should be the definition of Polyglot Markup be tightened to say that it defines the _biglot_ subset of HTML and XML? 
* Should the definition further be _expanded_ to say that that JavaScript libraries can be used -  in ways which are not compatible with this biglot subset - to create identical DOMs too?