Should support "text/xml" MIME media type

VERIFIED FIXED in mozilla0.9.5



17 years ago
17 years ago


(Reporter: Robert Crews, Assigned: peterv)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: PDT+[fixed on trunk])


(1 attachment)



17 years ago
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"?>
Ever confirmed: true

Comment 1

17 years ago
You're confusing the type attribute (defined in with the MIME type of the stylesheet. The
attribute specifies the style sheet language (see 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.
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 2

17 years ago
Hmm... The reference to the HTML spec referrs to the LINK element, not XML
processing directives. It's unfortunate that
 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

17 years ago
The HTML spec refers to LINK, but
 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

17 years ago
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.
Resolution: INVALID → ---

Comment 5

17 years ago
We should support application/xml too.

Thanks again for all your work on the project!

Comment 6

17 years ago
I'll seek clarification from the XSL WG.
Assignee: kvisco → peterv
Priority: -- → P5
Target Milestone: --- → Future
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.
Priority: P5 → --
Target Milestone: Future → ---

Comment 8

17 years ago
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.
Priority: -- → P4
Target Milestone: --- → mozilla1.0
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

17 years ago
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'?
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla1.0 → mozilla0.9.5

Comment 11

17 years ago
Created attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

Comment 12

17 years ago
Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml
Attachment #48831 - Flags: review+


17 years ago
Keywords: nsbranch
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.
Keywords: nsbranch → nsbranch+
Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

Attachment #48831 - Flags: superreview+

Comment 15

17 years ago
Checked into the trunk, leaving open for checkin into the branch.
Whiteboard: [fixed on trunk]

Comment 16

17 years ago
PDT+. Let's get some testing on this one.
Whiteboard: [fixed on trunk] → PDT+[fixed on trunk]

Comment 17

17 years ago
Checked in on the branch.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 18

17 years ago - can you verify this bug?  Thanks.

Comment 19

17 years ago
bitching buttons, verfication spam
You need to log in before you can comment on or make changes to this bug.