On Fri, Feb 8, 2013 at 9:58 AM, Larry Masinter <masinter@adobe.com> wrote:
> I had a recent insight about polyglot.
>
> Polyglot is the case where you have two languages A and B which have a substantial subset C in which every instance of C is also an instance of A and of B and the meaning of an instance h interpreted as A and interpreted as B is the same.
>
> The insight was that "polyglot" is an instance of a general technique for enabling transitions from one interface to another, whether that interface is a language or file format or API or network protocol or some extension of one of those.
>
> Polyglot is used for versions as well and extensions: it's what you do when you have incompatible changes in interfaces, or add new ways to do things. It's useful not just for languages but also for APIs and network protocols, or for extensions of any of those.
>
> Often someone who is publishing content in language A wanting to transition to language B with multiple recievers often can't force a "flag day" when all of the receivers. If there is a polyglot of A and B -- a useful subset C which can be interpreted both by A and B receivers, it allows the publisher to let the clients transition at their own pace.
>
> HTML/XHTML polyglot
>
> The original polyglot, in XHTML appendix C, was for enabling HTML -> XHTML transition. I think there are a number of people who are objecting that this is not a transition that is interesting or important.
>
> However, in 2013, the important use case for Polyglot is to allow the transitionfrom XHTML (the previous W3C Recommendation path) to HTML.
>
> Anyone who is currently publishing XHTML for use by XML-based processors, who can't afford a 'flag day', can start instead you publish, or implement, a 'polyglot' version which can be read/accepted/interpreted by both HTML and XML parsers.
>
> Some people would say that there are no XML parsers that people publishing HTML have to make sure not to break, and so there is no need to transition, so no need for polyglot. It would be useful to document use cases where this isn't true.
> Candidates include ePub, Atom RSS, XSLT users. If you have more, please speak up.
I believe HTML in the SVG foreignObject element is most useful when
represented in polyglot. Specifically, this HTML must be well-formed
XML (due to SVG wrapper) but it would be beneficial for reuse if
extraction yielded text/html-compatible markup. No metadata facility
to indicate this capability currently exists in these specifications,
afaik.
Hope this helps,
David