RE: Notes on the draft polyglot document Polyglot document

Thanks so much, Tim and the TAG, for the guidance and suggestions.


> 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

Awaiting verification from the WG. 
It looks like consensus points to "Polyglot Markup: HTML-compatible XHTML Documents." Will make that change once I verify consensus.

> 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 ""

3 & 4 done.

> 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.

Changed most sections to be normative rather than informative. Altered language to indicate where "a polyglot document is" where appropriate and kept RFC2116 language in the few places where it seemed necessary. I'd love feedback from anyone in the group as to the effectiveness of the changes.

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

Was there something in particular that you were thinking about here? I'd love a few examples, if possible.

> 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.

Again, thank you for taking the time to look this over.


Received on Thursday, 17 June 2010 18:40:39 UTC