85708 - Should support "text/xml" MIME media type

Status: VERIFIED FIXED

(Core :: XSLT, defect, P4)

Description

[Robert Crews]

The XSLT 1.0 spec says: "The MIME media types text/xml and application/xml
[RFC2376] should be used for XSLT stylesheets. It is possible that a media type
will be registered specifically for XSLT stylesheets; if and when it is, that
media type may also be used"; however, Mozilla does not import XSLT stylesheets
with the following: <?xml-stylesheet type="text/xml" href="test.xsl"?>, but does
import stylesheets with <?xml-stylesheet type="text/xsl" href="test.xsl"?>

Comment 1

[Peter Van der Beken [:peterv]]

You're confusing the type attribute (defined in
http://www.w3.org/TR/xml-stylesheet/) with the MIME type of the stylesheet. The
attribute specifies the style sheet language (see
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3.2) while the MIME type
specifies the type of the stylesheet file, which is text/xml or application/xml
because XSLT is an XML-based language.
We load the test.xsl stylesheet if you specify <?xml-stylesheet type="text/xsl"
href="test.xsl"?> and the server returns MIME type text/xml or application/xml
for the test.xsl file, so I'm marking this invalid. Hope that helps.

Comment 2

[Robert Crews]

Hmm... The reference to the HTML spec referrs to the LINK element, not XML
processing directives. It's unfortunate that http://www.w3.org/TR/xml-stylesheet/
 only shows text/css examples....

However, in XSLT: Programmer's Reference, Michael Kay says, "The processing
instruction has ... a type [pseudo-]attribute that indicates the language in
which the stylesheet is written. This doesn't have to be an XSLT stylesheet, it
could be CSS. The W3C Recommendation says that for XSL the media type should be
either text/xml or application/xml; however, with Microsoft's implementation in
Internet Explorer 5 it must be text/xsl."

In MSIE 5.5, text/xsl is still required, so apparently the spec is sufficiently
vague. I'm concerned, however, that text/xsl short-circuits the XSLT namespace,
which is where the processor should determine what type of stylesheet is being
used. If we use MIME types instead of namespaces, we might need text/xsl,
text/xslt, and text/xsl-fo, etc.

I'll leave this to you and the others to figure out. Thank you so much for
working on XSLT in Mozilla!!! It is just so cool!

Comment 3

[Peter Van der Beken [:peterv]]

The HTML spec refers to LINK, but http://www.w3.org/TR/xml-stylesheet/
 explicitly states: "This processing instruction follows the behaviour of the
HTML 4.0 <LINK REL="stylesheet">" and "The semantics of the pseudo-attributes
are exactly as with <LINK REL="stylesheet"> in HTML 4.0, with the exception of
the alternate pseudo-attribute."
You have a point about short-circuiting the namespace. But then again, the
stylesheet language is XSL, which afaik has no mime-type (IE set the precedent
of text/xsl). There apparently is an application/xslt+xml MIME type, so we
should probably add support for that, I'll try to find that out. I doubt that
we'll drop text/xsl as it is now widely used.

Comment 4

[Robert Crews]

I didn't really expect to pursue this more, but I really think this is a bug and
not an invalid request.

Here's further support: In Elliotte Rusty Harold's XML In A Nutshell, in the
section "Associating Stylesheets with XML Documents," he says, "type -- The
stylesheet's MIME media type; text/css for CSS and text/xml (not text/xsl!) for
XSLT." That is his parenthetical and exclaimation point, not mine.

I don't think these XML authors and I are all misreading the specification. I'm
not asking that we remove support for text/xsl, just that we support text/xml
like the specs say.

Comment 5

[Robert Crews]

We should support application/xml too.

Thanks again for all your work on the project!

Comment 6

[Peter Van der Beken [:peterv]]

I'll seek clarification from the XSL WG.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I agree that we should support what the spec states. However, as long as IE's
implementation remains broken, we should probably continue to support text/xsl.
I would like to see this fixed before 1.0.

I'll reset priority and target milestone for the duration of re-evaluation.

Comment 8

[Peter Van der Beken [:peterv]]

All major XSLT processors I know support text/xsl, period. I think this issue is
getting blown out of proportions, but it seems this is bothering some people so
much (why?) that i'll fix it by 1.0.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Since IE 6 just got slammed because it does not support text/xml I think it
would be nice if we could get this on the 0.9.4 branch... Additionally it seems
there is a mime type application/xsl+xml that should be supported (these +xml
types just seem to be popping up...). A 'hacky fix' that works for me seems to
be just to edit nsXMLContentSink::ProcessStyleLink() and if aType is any XML
type pass in text/xsl into nsXMLContentSink::ProcessXSLStyleLink(). Fixing it
for real is a bit more work but doesn't seem overwhelming.

Comment 10

[Peter Van der Beken [:peterv]]

This patch adds text/xml and application/xml. I haven't added
application/xslt+xml, it is not a registered MIME-type yet. Once (if?) it's
registered I'll add it. Looking for r and sr.
Heikki, why would this be a 'hacky fix'?

Comment 11

[Peter Van der Beken [:peterv]]

Attachment: Adds text/xml and application/xml

Comment 12

[Axel Hecht]

Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

r=[e-mail]

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Hacky because it does not change what is internally recognized by Transformiix,
thereby making it fragile if someone implements a new call to it. Also,
standalone Transformiix does not get the benefit. But, it is correct and safe
for now, so I say go for it.

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

sr=jst

Comment 15

[Peter Van der Beken [:peterv]]

Checked into the trunk, leaving open for checkin into the branch.

Comment 16

[Jaime Rodriguez, Jr.]

PDT+. Let's get some testing on this one.

Comment 17

[Peter Van der Beken [:peterv]]

Checked in on the branch.

Comment 18

[lchiang]

[e-mail] - can you verify this bug?  Thanks.

Comment 19

[Axel Hecht]

bitching buttons, verfication spam