- From: Robert Burns <rob@robburns.com>
- Date: Sat, 7 Jul 2007 10:50:12 -0500
- To: Robert Burns <rob@robburns.com>
- Cc: Philip TAYLOR <Philip-and-LeKhanh@Royal-Tunbridge-Wells.Org>, Ben Boyle <benjamins.boyle@gmail.com>, Mynthon Gmail <mynthon1@gmail.com>, public-html@w3.org
On Jul 7, 2007, at 10:37 AM, Robert Burns wrote: > > > On Jul 7, 2007, at 9:47 AM, Philip TAYLOR wrote: > >> >> >> >> Robert Burns wrote: >> >>> On Jul 7, 2007, at 6:26 AM, Ben Boyle wrote: >> >>>> I have noticed the W3C HTML validator is confused by <link ... / >>>> > and >>>> <meta ... /> empty tags, but had assumed it to be a valiator bug. >>> I would agree: validator bug. >> >> No bug (this needs to be said very clearly). The validator >> compares the document [1] with the DTD specified in the DOCTYPE >> directive, and finds bare character data. It goes on to >> explain : >> >> > Mistakes that can cause this error >> > include putting text directly in the >> > body of the document >> >> and that is effectively what the author has done, since >> the "/" closed the <link> tag and the following ">" >> closed the <head> element. Note that the diagnostic >> is effectively identical to that produced by the very >> example that the validator cites [2]. > > I understand. So call it a DTD bug. Or make a HTML 4.02 (or a > 4.01/1.0C) DTD and allow authors to use that. A new DTD could > explicitly prohibit NETs. The point is that if someone actually > wanted to use null end-tag terminators, those would work in > approximately 0% of non-validator HTML processing applications at > best. To me that's a bug in the validation process (even if not in > the validation code itself). I should also add that, in terms of our discussions here, this is not really relevant anyway. Our charter specifically says our non-XML serialization need not conform to SGML at all. Even if it did need to conform to SGML, we would be free to prohibit NETs in our non-XML serialization just as XML prohibits them in their SGML definition. What this means is that — following all of the objectives we've set for ourselves — our XML and non-XML serializations could be very close in syntax. I'm not sure if that's important, but in terms of the prospect raised here in this discussion, the likelihood is very high that we could provide very similar serializations. Take care, Rob
Received on Saturday, 7 July 2007 15:50:27 UTC