- 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