W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

Re: Backward-compatibility of text/html media type (ACTION-334, ACTION-364)

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
Message-ID: <OFD123DCA2.E7F09D42-ON852576BE.005651F1-852576BE.005766B7@lotus.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:19 GMT