Notes on the draft polyglot document Polyglot document

The TAG has reviewed the editor's draft  "HTML/XHTML Compatibility Authoring Guidelines"
http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html
as retreived 2010-06-09 CVS rev 1.14
We welcome this effort and have a few suggestions as follows.

1. The document should be couched as a specification. It specifies a set of documents, defined by various constraints,  most (though not all, because of the constraints on what scripts do) of which can be checked by a validator.   (This is useful spec, even though of course there are many types of document which are not exactly as defined which also have interesting properties).

2. Suggested title:  XML/HTML "Polyglot" Documents

3. The abstract should be an abstract of the document not information about it.
Suggested abstract:

Abstract:

A polyglot document is an HTML5 document which is at the same time an XML document and an HTML document, and meets a well defined set of constraints. Polyglot documents meeting these constraints are interpreted compatibly regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification. Polyglot documents use a specific doctype, namespace declarations, and a specific case, normally lower case but occasionally camel case, for element and attribute names. They use lower case for certain attribute values. Further constraints include those on empty elements, names entity references, and to the use of scripts and style. 

4. The original abstract should be moved into the SOTD section, as a new paragraph after "http://www.w3.org/TR/."

5. Much of the document then becomes normative, in the sense that the sepc is the definition of the polyglot set of documents.   The "non-normative" marks should be kept for only the non-normative comments.

  RFC2116 language should not be used in non-normative text. In normative text, as this is a specfication of a set of documents, we prefer the "A polyglot document is" to a "A polyglot document MUST be" style, as we are not talking about the behaviour of software.

6. We wonder whether there should be more advice about accessing the DOM from scripts.

7. Even though a validator cannot test whether the scripts in a document do the right thing, it may well be useful to write validators for the other constraints on ployglot documents. The document author should bear this in mind.


We are happy of course to discuss this if it doesn't makes sense.

Received on Wednesday, 9 June 2010 11:21:32 UTC