Re: W3C uri: /MarkUp

Masayasu Ishikawa <mimasa@w3.org> writes:

> . . .
> > There is still inadequate guidance unless one listens to individuals
> > who profess knowledge of the right thing.
> 
> It is well-known that MIME media types don't work well with mixed-
> namespace documents.  ...

Mime content types are *triggers* for application classes.  If a
content type is so broad that there is no obvious (in the sense of
what an economist would call a "focal point") class of applications
that are safe for automatic invocation on content delivered across the
network, then the use of that content type outside of the context of a
secure local network is unwise and should be discouraged.

>                  ...  There is an extensive discussion about media
> types on the Technical Architecture Group [1], and out of this
> discussion, an Internet Draft was written about "Registration of
> xmlns Media Feature Tag" [2].  While this I-D is still just an idea
> and has no official status, this could be a way to cope with mixed-
> namespace documents in MIME context.  An example in this I-D
> describes how to identify an XHTML document containing SVG, MathML,
> SMIL, and XLink content, using a combination of the Content-Type
> and Content-Features headers.

This draft -- in the context of "text/xml" and "application/xml" (RFC
3023) -- does not hold promise of a solution to the issue here.

Those who advocate the class of mass market user agents for "text/xml"
(or "application/xml") are by consequence advocating the appropriation
of this content type for HTML-descended XML document types to the
exclusion of richer document types such as CALS, DocBook, and TEI, not
to mention the whole EDI family of document types.

> RFC 3236 doesn't magically solve the media type woes, but it's
> a step forward.

Agreed.  It's a far better choice for XHTML than any of the RFC 3023
types, and it's certainly useful for transition.

But, long term, do we want to have two obvious application classes
for HTML, one ("text/html") for classic HTML and the other
("application/xhtml+xml") for the XML form of HTML?

It is a separate, relatively minor, question whether some dually
capable user agents will reasonably want simple mime-level information
for a parsing decision.  Namespace-based choice of application class
is simply too complicated to be viable, and parsing decisions do not
require namespace information.

If, long term, there is just going to be one application class, then
long term use of the second content-type simply burdens content
providers because those who provide user agents lack agreement on how
to proceed.

In fact, XHTML, even without strict observance of the compatibility
guidelines, can be reasonable tag soup.  If we want content providers
to cooperate and use it, we shouldn't impose the expense of dual
content type service on them as a cost of using it.

                                    -- Bill

Received on Monday, 25 February 2002 14:46:30 UTC