- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 2 Feb 2010 10:58:03 -0500
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: "Dan Connolly" <connolly@w3.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Julian Reschke" <julian.reschke@gmx.de>, www-tag@w3.org
Anne van Kesteren writes: > Actually, you can, it just won't be conforming. You can serve > "foobar" as text/xml too. Without commenting on the merits of the other points made in this thread, but I would much rather not pursue that line of reasoning. It seems to me that, underlying this discussion, is (should be) a desire to use the media type registration and associated HTML specifications to promote interoperability, and to resolve questions when in fact interoperability breaks. In particular, one of the things that good specifications due (I know I'm stating the obvious), is to help decide where the error is when things don't work. Since we're talking about the text/html media type registration, the obvious cases of interest are ones in which a user agent has used HTTP and retrieved a representation with that media type, and in which the entity-body was coded to conform to an earlier version of the HTML recommendation. Let's now consider two alternatives with respect to the media type registration: 1. The new text/html media type registration takes care, through whatever means, to ensure that documents written to older versions of HTML are conforming to the new registration If a user agent fails to properly interpret some of the document, then we can unambiguously determine that the user agent is buggy. The line of reasoning is: RFC 2616 defined conformance for the HTTP interaction; it stated that the media type registration for text/html was normative in this case; the content is provably conforming to the registration (I.e. because we're talking about the case where the registration does grandfather old HTML as conforming.) 2. The new text/html media type registration says that documents that (cause no parse errors?) per the HTML 5 Recommendation (implicitly, to paraphrase Anne, "you can also serve HTML 2...it just won't be conforming") In this case, if old HTML 2 is served, the line of reasoning becomes: RFC 2616 defined conformance for the HTTP interaction; it stated that the media type registration for text/html is normative in this case; the HTML 2 content is provably nonconforming to the new media-type registration; the failure is the fault of the server. That's the choice, I think. I prefer #1. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Anne van Kesteren" <annevk@opera.com> Sent by: www-tag-request@w3.org 02/02/2010 10:08 AM To: "Julian Reschke" <julian.reschke@gmx.de>, "Dan Connolly" <connolly@w3.org> cc: "Henry S. Thompson" <ht@inf.ed.ac.uk>, www-tag@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: Re: Backward-compatibility of text/html media type (ACTION-334, ACTION-364) On Tue, 02 Feb 2010 16:05:30 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > So, just to be clear: once the text/html registration is changed to > HTML5, I can't serve > > http://greenbytes.de/tech/webdav/rfc2616.html > > as text/html anymore, as the document does not conform to HTML5 (due to > head/@profile). Unless, of course, the definition of conformance is > changed back to allow it. Actually, you can, it just won't be conforming. You can serve "foobar" as text/xml too. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 2 February 2010 15:56:00 UTC