Closed Bug 85708 Opened 23 years ago Closed 23 years ago

Should support "text/xml" MIME media type

Categories

(Core :: XSLT, defect, P4)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: rcrews, Assigned: peterv)

Details

(Whiteboard: PDT+[fixed on trunk])

Attachments

(1 file)

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"?>
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
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!
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.
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
We should support application/xml too.

Thanks again for all your work on the project!
I'll seek clarification from the XSL WG.
Assignee: kvisco → peterv
Status: REOPENED → NEW
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 → ---
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.
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'?
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla1.0 → mozilla0.9.5
Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

r=axel@pike.org
Attachment #48831 - Flags: review+
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: nsbranchnsbranch+
Comment on attachment 48831 [details] [diff] [review]
Adds text/xml and application/xml

sr=jst
Attachment #48831 - Flags: superreview+
Checked into the trunk, leaving open for checkin into the branch.
Whiteboard: [fixed on trunk]
PDT+. Let's get some testing on this one.
Whiteboard: [fixed on trunk] → PDT+[fixed on trunk]
Checked in on the branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
kvisco@ziplink.net - can you verify this bug?  Thanks.
bitching buttons, verfication spam
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: