OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad News on IE6 XML Support

* Joshua Allen wrote:
>>The new MIME type for XSLT will by the way be application/xml+xslt, not
>>text/xml+xslt, at least this is outlined in section 8.17 of RFC 3023,
>Thanks for the correction.  Actually, it looks like the convention is

Yes, ...

>and the '+xml' part is optional.  In other words,
>section 8.17 just seems to be saying that whatever mime type for XSLT
>eventually gets registered should also stick a +xml after it (but also
>the version without +xml would be accepted).  In fact, the spec makes it
>clear that application/xslt is just an example, since no type is yet
>registered.  I may be totally blind, but it looks to me like section
>8.17 is not at all negating the possibility that text/xsl would be the
>standard mime type, and is also not saying that it would be wrong to
>leave off the '+xml'.

Yes, '+xml' is just a convention and there are already MIME types
(registered prior to RFC 3023) violating this convention, e.g.
text/vnd.wap.wml but most newly registered MIME types adhere to that
convention, e.g. application/vnd.mozilla.xul+xml, application/beep+xml
and application/vnd.irepository.package+xml.

If Microsoft goes and registers text/xsl (Microsoft propagates and
requires it's use, so they are in charge to do it) to standardize common
practise or a defacto standard, the XSLT community would be quite happy,
even if we then end up with two MIME types for XSLT. An alternative
would be to register both MIMT types in a single RFC, but I don't think
the W3C Style activity is willing to do so, even if they are responsible
for text/xsl in the first place.

>I admit I am no
>expert on mime types, but it seems that application/xslt+xml would be
>preferable as a "best practice" to text/xml or application/xml.  But
>then that '+' seems like some sort of trick which parsers can choose to
>treat differently, so in that case text/xsl+xml would be better since it
>would mean that text/xsl could continue to work.

I didn't take part in the discussion around RFC 3023, so I guess Simon
St. Laurent or someone else would be a better person to turn to.

>Anyway, sorry if I am missing something, but as far as I can tell there
>is not even a media type for XSLT yet (and the RFC says that the media
>type in the example SHOULD NOT be used until a real media type gets
>registered).  And again, I may be missing something major, but why
>wouldn't text/xsl+xml be the natural thing that got registered, since
>that is the de-facto standard now anyway?

Yes, there isn't any XSLT MIME Type and the W3C Style Activity still
hasn't submitted any Internet Draft for a proper registration. RFC 3023
lists some reasons why application/* is preferred to text/*.
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/