W3C home > Mailing lists > Public > www-html@w3.org > April 2003

Re: XHTML2 MIME type

From: Masayasu Ishikawa <mimasa@w3.org>
Date: Fri, 11 Apr 2003 16:13:29 +0900 (JST)
Message-Id: <20030411.161329.74741455.mimasa@w3.org>
To: www-html@w3.org

[ personal opinion ]

Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> >Current WG position is that we'd use 'application/xhtml+xml', with
> >optional 'profile' parameter to indicate XHTML2, if necessary.
> This reminds me to the success stories of the `level` and `version`
> parameters of text/html...

It was so successful enough to be dropped from RFC 2854.

> Does the HTML WG consider it likely that
> User Agents with XHTML 2.0 support will send
>   Accept: application/xhtml+xml;profile="http://www.example.org/xhtml2",
>           ...
> and that support for such parameters is good enough among common server
> configuration and content negotiation facilities that authors will
> actually be able to deliver XHTML 2.0 documents only to user agents with
> explicte support for these documents?

As I noted in earlier message, neither new media type nor optional
parameter can address how to deal with hybrid XML document well.
People might want to deliver a variant of XHTML2 document which
includes MathML and SVG and another variant which is a "plain" XHTML2
document, but media type alone provides no clue to differentiate those
two variants.  In some sense the profile parameter *could* provide
some clue if it's desperately necessary, but personally I don't expect
wider use of it.  As clearly noted in RFC 3236, the profile parameter
"is meant to solve the short-term problem", and I hope there will be
a better way of dealing with this problem, not just for XHTML.

In my impression the WG's current order of preference would be
something like this:

  1. use 'application/xhtml+xml', with optional profile parameter
     if necessary
  2. register a new media type
  3. just use 'application/xml' (and hope there will be a better way
     of handling hybrid documents)

Registering and deploying a new media type take time.  Until both
user agents and servers provide enough support for a new media type,
people might well end up using 'application/xml' or something for
the time being, so we'd need a solution for that anyway.

About media type and versioning, SMIL may be considered as a precedent.
Although it is still an Internet Draft, 'application/smil' (for
historical reason) and 'application/smil+xml' will be registered
for both SMIL 1.0 and SMIL 2.0 [8].

> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
> [2] http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-03.txt
> [3] http://www.w3.org/2001/tag/ilist#nsMediaType-3
> [4] http://www.w3.org/2001/tag/ilist#mixedNamespaceMeaning-13
> [5] http://www.w3.org/2001/tag/ilist#mixedUIXMLNamespace-33
> [6] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
> [7] http://www.w3.org/2001/tag/ilist#RDFinXHTML-35

[8] http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-11.txt

Masayasu Ishikawa / mimasa@w3.org
W3C - World Wide Web Consortium
Received on Friday, 11 April 2003 03:13:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:03 UTC