W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 11755] The introduction should be clearer about use cases best addressed by polyglot markup

From: <bugzilla@jessica.w3.org>
Date: Sat, 12 Feb 2011 01:04:54 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Po3uw-0000f2-QY@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11755

Eliot Graff <eliotgra@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Eliot Graff <eliotgra@microsoft.com> 2011-02-12 01:04:54 UTC ---
The 11 February Editor's Draft has the following expanded Introduction:

]]
It is often valuable to be able to serve HTML5 documents that are also well
formed XML documents. An author may, for example, use XML tools to generate a
document, and they and others may process the document using XML tools. The
language used to create documents that can be parsed by both HTML and XML
parsers is called polyglot markup. Polyglot markup is the overlap language of
documents that are both HTML5 documents and XML documents. It is recommended
that these documents be served as either text/html (if the content is
transmitted to an HTML-aware user agent) or application/xhtml+xml (if the
content is transmitted to an XHTML-aware user agent). Other permissible MIME
types are text/xml, application/xml, and any MIME type whose subtype ends with
the four characters "+xml". [XML-MT] 

Polyglot markup: 
•is valid HTML5. [HTML5]
•is well-formed XML. [XML10]
•results in identical DOMs (with the exception of the xmlns attribute on the
root element) when processed as HTML and when processed as XML.

Polyglot markup is not constrained: 
•to be valid XML. [XML10]
•by conformance to any XML DTD.

 All web content need not be authored in polyglot markup. Polyglot markup is
ideal for publishing when there's a strong desire to serve both HMTL and XML
tool chains without simultaneously having to maintain dual copies of the
content: one in HTML and a second in XHTML. In addition, a single polyglot
markup output requires less infrastructure to produce than to produce both HTML
and XHTML output for the same content. Polyglot markup is also be beneficial
when lightweight processes—such as quick testing or even hand-authoring—are
applied to content intended to be published both as HTML and XHTML, especially
if that content is not sent through a tool chain. 
[[

I believe this satisfies the request for more concrete use cases and advice in
#1. I take it that this is the main thrust of this bug and will resolve it as
fixed. If you wish to follow up on the other points, please file separate bugs,
so we can more easily track them, OK?

For #2, if you had an xml serializer that was outputting polyglot, tool chains
can then become aware of polyglot and change to output polyglot. The benefit is
that you don't need an explicit decision ahead of time as to whether you serve
to XML or HTML. 

For #3, arbitrary input could be either XML or HTML. For input, polyglot may
not be the best case. For input for things you have no control over, you're
right, and so I mention in all cases the benefit for serving content. 

For #4, that was an omission. Thanks for the catch. I've changed the
introduction to contain the following:

]]
It is recommended that these documents be served as either text/html (if the
content is transmitted to an HTML-aware user agent) or application/xhtml+xml
(if the content is transmitted to an XHTML-aware user agent). Other permissible
MIME types are text/xml, application/xml, and any MIME type whose subtype ends
with the four characters "+xml". [XML-MT] 
[[

Thanks, once more, for all the great work.

Eliot

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 12 February 2011 01:04:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 12 February 2011 01:04:56 GMT