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

[Bug 11910] @id values in polyglot markup should be XML-valid (or not?)

From: <bugzilla@jessica.w3.org>
Date: Sun, 30 Jan 2011 17:42:31 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PjbIF-00056o-KF@jessica.w3.org>

--- Comment #8 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-01-30 17:42:30 UTC ---
(In reply to comment #7)
> (In reply to comment #6)

> > HTML5 also mention it in
> > the "restrictions on the content model" seciton. It would be simple to provide
> > a list of those element that have special parsing attached to them.
> You would also have to say exactly what the special parsing rules are,

Isn't it a good start to just list them? Just create a header saying "the
following features are autogenerated if you don't insert them, and must
therefore be explicitly added for DOM compatibility". And then list the

> and what
> subset of well formed documents produce compatible xml parse trees despite
> those rules. This would make the polyglot many many times larger than it
> currently is, for very little benefit, and the chance of getting it right would
> be close to nil. For conforming documents the rules are irksome but not too
> difficult to state, but for non conforming, documents the rules are massively
> more complicated.

How about discussing this in bug 11909? I must admit that I have not had in
mind creating such a large document as you think that what I say would have
lead to.

> > Here I think you are mixing things: XML is not alone in discerning between
> > "working" (aka "well-formed") and valid (aka "conformance"). HTML has the same
> > concept.
> Not really, html(5) produces a parse tree for (almost) any input, just some
> inputs are declared non conforming.

Formally you are correct, I guess. 

But we could also say that HTML(5) has another consequence of being
unwell-formed: soft-punishment instead of yellow-screen-of-death.

I think those errors that are related to wrong nesting can be placed in the
un-well-formed category.

> >  E.g. HTML5 says that it is forbidden to set the value of the img@border to a
> > non-zero value. Thus, this is forbidden <img border="9" src="i" alt="i">. We
> > can both agree that it is not an issue, with regard to getting the exact same
> > DOM, whether @border is set to "9" or "0". 
> The fact that there are a few non conforming documents for which it is possible
> to say something about xml parsing isn't enough to justify saying anything
> about them here.

I argue for operating with clear concepts. I don't argue for talking about

> > If this document is supposed to replace Appendix C, then it must, in my view,
> > also describe principles.
> I can't imagine any reason to make the document many many times longer just to
> tell people how they can use xml tools to make non conforming documents rather
> than just saying how to produce conforming documents.

Me neither. Neither do I get where you take it from that that is what I argue

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 Sunday, 30 January 2011 17:42:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:04 UTC