RE: [xml-dev] Registration status

David, as the co-author of RFC 3023, I would appreciate if you would
reread it.  We covered these issues in an extensive mailing list
archive, but tried to distill them into appendix A.

Specifically, MIME is not solely handled by web browsers.  Email agents
are also MIME dispatchers, as are NNTP and BEEP clients (and soon IM).
It is very unlikely that all XML-based MIME types seen by these agents
(none of which currently understand namespaces, although at least BEEP
parses XML) should be dispatched to the same XML application.  Think
application/calendar+xml versus image/svg+xml.

Now, I agree that compound types cannot be handled ideally by MIME, but
the MIME concept of dispatching to the correct application is still
useful.  In particular, an XHTML+MathML document quite possibly needs to
be handled by a different application (say Mozilla) than default unknown
XML types (which might want XML Spy).

As to web hosting, I agree that users need more control over MIME types
than they're currently getting.  Although it's not a good ultimate
solution, the use of file suffixes has served as an implicit mapping for
MIME types.  Thus, web servers can (and, IMHO, should) be configured so
that .xhtml is served as application/xhtml+xml and .xml as
application/xml.  Things like XHTML+MathML documents that are likely to
be successfully dispatched using namespaces by XHTML renderers should
use the .xhtml extension and application/xhtml+xml.

This of course, is all IMHO, as RFC 3023 explicitly supports you serving
all XML as application/xml if you really want to.  But as A.15 mentions,
there are no apparent downsides from using custom types and several
advantages.

		- dan
--
Dan Kohn <mailto:[email protected]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email protected]>

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of David Carlisle
Sent: Sunday, October 28, 2001 14:15
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [xml-dev] Registration status




> I doubt that's necessary in the general case.  It is typically
> sufficient that the media type is used to dispatch the processor
> that recognizes the root element, permitting further internal
> namespace dispatching independant of the media type.  That's the
> case for XHTML at least.

I'm not sure I follow this at all. You use the present case, but are
there any current applications that would work if the document was sent
as xhtml+xml but wouldn't if it was sent as xml? If the xnl file is
explicitly styled (with xslt or css) then surely just xml semantics is
sufficient. If not, then having it sent as xhtml+xml might allow a
default style to be applied (but as mozilla shows that's possible just
using the namespace, and the latter has definite advantages when you
discover elements in the mathml namespace half way down the page)



> This [dispatching on namespace] will happen eventually, but it can't
> yet be assumed that a receiving agent will dispatch on a namespace, or
> have any means of configuring namespace/processor bindings.  So for
> the next little while, there'll be some value in media types.

I'm not sure. Today I can have an xhtml+mathml document and on any
processor with a client side xslt (IE5/msxml3,IE6,Mozilla,NS6) I can
cause "whatever is needed" to happen on the client side by having the
client side XSLT transform the inline namespaced elements to whatever
that client needs to display that language. This works now, but a) I
don't know when the clients will be able to handle *+xml mime types out
of the box, and I don't know when if ever "basic" ISP's will allow
customisation of the outgoing types.

I want it to be as easy to put a xhtml+mathml page on the web as it is
to put an html page including tables. ie anyone with a dialup account to
ought be able to do it. If it means configuring the server to send
different mime types depending what's in the document, it doesn't really
work.

David




_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.