This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As I noted in Bug 9965, Canonical XML - aka C14N - have some requirements that looks like relevant design principles for Polyglot Markup - at least in some stake holders' opinions. For example C14n requires: * that <li/> should be written as <li></li> * that document uses UTF-8 * that class=" one two" is written class="one two" * XML declaration must be removed For overview: http://www.w3.org/TR/xml-c14n#Terminology Hence i suggest as a design principle for the Polyglot Markup that the XML requirements should be based on Canoncical XML - except when that principle is incompatible with HTML5. (One place where it is incompatible is in C14N's requirement to remove the DOCTYPE).) Positive: Adopting such a principle would make it simpler to justify and agree about the design of Polyglot Markup. Negative: The requiremetns of C14N are, however, stricter than the the _real_ requirements of Polyglot Markup. JUSTIFICATION: It seems to be the case that quite a few people with a stake in Polyglot Markup wants to base the polyglot requirements on something that is stricter thant the the _real_ requirements. And because of that, I think it is important to have something solid to base those extra requirements on. Rather than randomly picking one's favorite restrictions/permissions. (For example, there are conditionas when it is not necessary to write <li/> as <li></li> - even when the document is meant to be polyglot. But instead of defining the exceptions - or our own restrictions - we could simply pick Canonical XML's rulings as base.)
I guess, that that this bug can be closed ... The main service Canonical XML can do to us may be that it a) can serve as example of what "plain" XML does _not_ require. Plain XML does not remove multiple spaces in the DOM. On the other side, C14N also shows us that many of the HTML5 requirements, can also find justification in C14N. But the polyglot spec should be based on compatibility with "normal" XML.
See Leif's comments.