Polyglot: the final thread?

Hi everyone,

As promised, I spent time looking into the history of the current polyglot
work, the TAG's involvement, and the options for all parties.

There is, I hope, uncontentious background. To recap what I've learned:


   - *Polyglot exists in the wild.* It is possible to write documents
   served as "text/html" that would parse both as HTML5 and as XML.
   - *Nobody knows how popular it is.* The lack of signage, coupled with
   default in-browser parsing as HTML means that few on any side of the debate
   understand to what extent producers are creating this sort of content. It's
   difficult to draw any conclusions about importance based on a lack of
   information either way as a result.
   - *Polyglot markup has little impact either on XML or HTML. *HTML is
   tightly constrained by DOM coherence between HTML and XHTML DOM
   serializations. This is a stronger constraint on the evolution of the
   parsing algorithm than anything Polyglot has come up with or is likely to.
   XML, as the stricter subset, is unbothered. There's a honeybadger meme in
   there somewhere.
   - *The HTML WG may product a Polyglot document with or without the TAG's
   request. *The specifics of why the TAG decided to jump on issuing a
   request are fuzzy, but it doesn't seem to matter. The TAG's request (or
   absence) has no impact on process from here. Polyglot is inside the HTML
   WG's charter and is proceeding towards publication. Maintaining or
   rescinding the request will not change that. At some point in the future,
   the Polyglot document will come up for a vote as to REC or NOTE. This will
   not be affected *in any way* by the TAG.

Now, as to what the TAG can and should do, I'll editorialize a bit;
apologies in advance:


   - The current and past TAG members do not agree that the outstanding
   request speaks to any core architectural principle. That the HTML WG has
   identified the subset and is describing it  may be good; but no better
   perhaps than naming the comment escaping hacks that would let you nest XML
   and JS in the same document (as I did for generating
   Docbook documentation from my very first JS toolkit).
   - The utility of polyglot is in dispute.
   - There's worry that if sent to REC (with our without the TAG's
   request), it will be seen as being being something the W3C *wants* authors
   to do; not merely something that authors *can* do (or may happen into).
   Some see the TAG's request as a vote in this direction. A community of
   people find some value in the subset today, but there's very little data to
   say that the architecture of the web will be bolstered by creating more
   Polyglot-published content.
   - There's no way to know besides double-parsing should that future
   arrive and nobody is doing this over a large enough body of content to
   determine if there is more or less polyglot content today vs. yesterday. It
   does not appear this will change.

As a result of all of the above, having (I hope) fairly weighed the
arguments, I would like to recommend that we find a way to extricate
ourself from the request. It doesn't matter to the future of Polyglot, and
it does not, in my view, serve the TAG to be in the middle of this.
Polyglot can have whatever future it will in the W3C without our group
involvement.

Thoughts?

Regards