W3C home > Mailing lists > Public > www-tag@w3.org > March 2013

Re: Polyglot: the final thread?

From: Larry Masinter <masinter@adobe.com>
Date: Tue, 12 Mar 2013 19:14:21 -0700
To: Alex Russell <slightlyoff@google.com>
CC: "www-tag@w3.org" <www-tag@w3.org>, Sam Ruby <rubys@intertwingly.net>, Henri Sivonen <hsivonen@iki.fi>, Jeni Tennison <jeni@jenitennison.com>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <8rwdox69nlwb3xl03470nfv1.1363132688558@email.android.com>
I think polyglot is a general important technique for transitioning languages, interfaces and protocols, and the TAG could do most good by understanding and explaining it.
Whenever you need to transition a one-to-many system without a flag day, t
you need polyglot or a variant to allow the transition.

Larry
--
http://larry.masinter.net


Alex Russell <slightlyoff@google.com> wrote:

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
Received on Wednesday, 13 March 2013 02:14:57 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 13 March 2013 02:14:58 GMT