- From: <bugzilla@jessica.w3.org>
- Date: Sat, 12 Feb 2011 01:04:54 +0000
- To: public-html-bugzilla@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 UTC