- From: David Dorward <david@dorward.me.uk>
- Date: Thu, 05 Apr 2007 22:33:10 +0100
- To: Shane McCarron <shane@aptest.com>
- CC: www-validator@w3.org
Shane McCarron wrote: > When attempting to validate this, the validator complains that the > referenced DOCTYPE, admittedly a private, contrived markup language that > the validator does not know about explicitly, is being served as > text/html and it cannot decide how to parse it. Which is unsurprising since you should not serve private, contrived XML dialects as text/html (Appendix C XHTML has caused enough problems already). http://www.w3.org/TR/xhtml-media-types/#summary SHOULD NOT is RFC 2119 speak for (to paraphrase) "Don't do this unless you understand and are comfortable with the consequences". SGML and tag soup slurpers having issues is such a consequence. Having "]>" render at the top of the document in my browser of choice is another consequence. Making the W3C look like numpties who write specifications (like RFC 2854) and then fail to follow them is another consequence. The application/xml MIME Type exists for this sort of thing. Hacking quality assurance tools to ignore the specification is not as good a solution as following the specification. > Now... I know that I could change the rules so that a requestor who > accepts application/xhtml+xml would get the document with that media > type, but... I think of the document starts off with an "xml" > declaration, e.g., <?xml ... ?>, then the validator should assume that > the document is to be validated in XML mode. If clients are going to sniff the document to decide how to handle it, then it renders the Content-Type header pointless. The Content-Type header, however, handles the issue far more elegantly (exposing the information to HEAD requests for example). -- David Dorward <http://dorward.me.uk/>
Received on Thursday, 5 April 2007 21:33:30 UTC