With shared-mime-info 0.15 the current mime type of XSLT stylesheets (*.xsl and *.xslt) is text/x-xslt. Shouldn't this be either text/xml or application/xml. According to the XSLT 1.0 specification these should be used, http://www.w3.org/TR/xslt#section-Introduction last paragraph (though the currently unreleased xslt 2.0 spec suggest application/xslt+xml, but that's not relevant yet). The current setting causes firefox to not work with client-side xsl on the local file system. (https://bugzilla.mozilla.org/show_bug.cgi?id=272310 and debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281894)
RFC 3023 defines the application/xstl+xml content type, I'd prefer to use that since it's more specific than application/xml or text/xml. Any objection? Could you check whether firefox works with application/xslt+xml or not?
I committed the application/xslt+xml to CVS, please reopen this bug if this is wrong, I'm not really sure what's best in this case, thanks for the bug report and the useful links!
Everything looks fine. Debian users report success using a patch I sent them based on your committ. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281894 for more details
Great, thanks for the follow-up However, it would be great if the reporter could test it with local files, since the mozilla bug seems to indicate it's only an issue with local files (unless the reporter can confirm it doesn't work with the online webservice and without the patch). Sorry for not directly posting to this debian bug, but I never remember how to use your bts ;)
Ok. This doesn't work with local files. Both I and another user have tested this on firefox 1.0.2. We can also confirm that setting the XSL mime type to either text/xml or application/xml does allow local xsl files to work in firefox. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281894 for more info and some small xsl and xml files which can be used to test.
By setting application/xslt+xml we are saying we do not accept XSLT 1.0 documents. We should only be using application/xslt+xml when we know for a fact that the document is XSLT 2.0 or greater. Since we cannot possibly know that via the filename glob, we should not be reporting that information. Additionally, Gecko is not aware application/xslt+xml. (N.B: Firefox 1.1 Alpha versions currently have a bug where all mimetypes are accepted for XSL processing). Solution: we should report the MIME type for *.xslt and *.xsl as text/xml (we only know it is a text file, not whether it is an application, therefore should not claim more than we know about it, and is also the least common denominator to get XSL working).
Hi, the change that has been applied to version 1.54 in CVS, i. e. changing the mime-type to "application/xslt+xml" does not work (for me). The same (does not work) is reported at "bugs.debian.org": http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281894 In the mentaime I've filed a bug at "gentoo.org" requesting to patch "freedesktop.org.xml" in their "ebuild": http://bugs.gentoo.org/show_bug.cgi?id=101207 Why not change the mime-type to "application/xml"? It's not a perfect solution and does not (fully) comply with XSLT 2.0 but it works! :-) Cheers, Axel
Christophe, Bastien, do you agree with Axel? I'd rather have something working than something spec-compliant that doesn't work :).
Hmmh, starting with version 1.99 of "freedesktop.org.xml.in" the mime-type "text/xml" has been renamed to "application/xml"... ... but for XML documents ("*.xml") not for XSL transforms/styleheets. XSL transforms/stylesheets ("*.xsl","*.xslt") are still mapped to "application/xslt+xml". Is this by intention? Cheers, Axel
Hmmh... nobody else who thinks that this should be fixed? I've just checked out HEAD of "shared-mime-info" from CVS, build and installed it... As expected mozilla (firefox) does still not recognize "application/xslt+xml" as a valid mime type for XSLT stylesheets and the sub-class specification ("application/xml") is ignored (by the gnome-vfs OS backend). So I give up on hoping that "upstream" (mozilla.org || freedesktop.org) would prefer "something that works" over "something that is standard compliant", although this is quite unsatisfying, because I'm massively using locally stored XSL files to create (pretty-rendered) HTML from (simple-edited) XML. To avoid (manual) patching the "freedesktop.org.xml" mime-package each time it is updated on my gentoo box, I've searched for a persistent workaround... and finally found a nice and simple one: (1) Reading http://www.mozilla.org/docs/web-developer/mimetypes.html#ehas and comparing the description of the mime-type lookup algorithm with current "seamonkey" code reveals that the description is WRONG, i. e. user supplied "mime mappings" ("mimeTypes.rdf" in the users's "profile" folder) are checked BEFORE asking the OS. See: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2633 (2) Reading http://kb.mozillazine.org/MimeTypes.rdf to learn about the syntax of the "mimeTypes.rdf", comparing the given information and doing some tests reveals that the file extension is specified using "NC:fileExtensions" (plural) and NOT "NC:fileExtension". (3) Adding a "<RDF:Description />"-element for .xsl (and .xslt) files to the very end (actually the position does not matter) of "mimeTypes.rdf" in my firefox profile folder that maps the extension(s) to a mime type of "application/xml" does the trick. (4) If just mapping a single extension (.xsl) to "application/xml", "NC:fileExtensions" can be given as an attribute of the <RDF:Description/>-element (see: Example A). To map more the one extension (.xsl and .xslt) sub-elements <NC:fileExtensions /> have to be used (see: Example B) (Example A) == mimeTypes.rdf ==================================================== <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> [ ... ] <RDF:Description RDF:about="urn:mimetype:application/xslt+xml" NC:description="XSLT stylesheet" NC:value="application/xml" NC:fileExtensions="xsl" /> </RDF:RDF> ======================================================================= (Example B) == mimeTypes.rdf ==================================================== <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> [ ... ] <RDF:Description RDF:about="urn:mimetype:application/xslt+xml" NC:description="XSLT stylesheet" NC:value="application/xml"> <NC:fileExtensions>xsl</NC:fileExtensions> <NC:fileExtensions>xslt</NC:fileExtensions> </RDF:Description> </RDF:RDF> ======================================================================= NOTE that "mimeTypes.rdf" has to be edited (saved) while firefox (mozilla) is NOT running! For this is a workaround that permanently solves the "mozilla XSL mime-type issue", I think that this (reopened) bug can be closed, now. Feedback is very much appreciated. Axel
Yep, I'm fine with changing it, I had made it what it is, because it seemed better, obviously I didn't know that would break stuff at that time, I also prefer something that works that something 100% spec compliant :)
Wow, this would be great! ... although it would make my workaround -- that I'm quite proud of -- obsolete. ;-) By-the-way and for clarity: Your change did not break anything. The previous or rather the still current (0.16-release) mime type (text/x-xslt) did not work either. :-) The actual problem -- beside of the mozilla browsers not supporting the XSLT 2.0 mime type -- is that applications (browsers, file managers, ...) should NOT expect a SINGLE value when asking the "OS" (gnome-vfs) for the mime-type of a file but INSTEAD a LIST of mime-types ordered from the most specific to the most general value (==> mime "sub-classes"). I think that there already was a similar dicussion on the nautilus development list... Cheers, Axel
> The actual problem -- beside of the mozilla browsers not > supporting the XSLT 2.0 mime type -- is that applications > (browsers, file managers, ...) should NOT expect a SINGLE > value when asking the "OS" (gnome-vfs) for the mime-type > of a file but INSTEAD a LIST of mime-types ordered from the > most specific to the most general value (==> mime "sub-classes"). We already do this for GnomeVFS, and we did our best to fix this in the 2.13.x series. I think we can really fix this without beaking XSLT 2.0 compliance. I'm on GnomeVFS HEAD and shared-mime-info HEAD and both test cases from the referenced bug report are assigned the correct MIME type. This was possible due to some extra sniffing code that was added. Grep for xdgmime under [1] to see the actual code. The problem was that we randomly preferred one MIME type over the other one when both had the same priority and both matched the contents. [1] http://mail.gnome.org/archives/gnome-vfs-list/2006-February/thread.html
Hmmh... don't know, if I get you right. What I've understood is: If I would build and install share-mime-info AND gnome-vfs from CVS (HEAD) or wait for gnome-2.14 to be released -- which will include the changes -- the mime-type that would be reported for XSL files would be "application/xml", because of the "content sniffing match" having higher priority than the "file extension match". Right? While this would make nautilus detect the mime-type correctly, I do not think that mozilla/firefox could also benefit from the change. In case of local (XSL) files mozilla tries to derive the mime-type purely from the extension, i. e. information about the full path of the file is (already) lost and this makes content sniffing rather difficult. :-) Tracing down mozilla's mime-type detection for local files on Unix (GTK/GNOME) platform lead me to http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/unix/nsGNOMERegistry.cpp#268 which illustrates the problem quite clearly, I think. Maybe mozilla is going to fix this or rather has already fixed this on the 1.8 branch which would solve the issue for me as soon as I update to mozilla/firefox(s) based on the newer branch. See: * https://bugzilla.mozilla.org/show_bug.cgi?id=249153 * https://bugzilla.mozilla.org/show_bug.cgi?id=259206 Meanwhile I have a workaround. :-) Cheers and Thanks, Axel
Addition: I've just checked out and build HEAD of "xdgmime" from CVS which already has the "had_match" patch applied... test-mime <some-xsl-file> --> xdg_mime_get_mime_type_for_file (<some-xsl-file>,...) --> _xdg_glob_hash_lookup_file_name(...,basename(<some-xsl-file>), ...) ... which returns 1, because there is exactly one entry that has a matching glob-pattern (*.xsl). So _xdg_mime_magic_lookup_data() is never called, i. e. I can't see, how recent change(s) would effect mime-type detection for XSL files. ... though this does not mean anything, because it's late and it's getting difficult to keep eyes open. :-) Axel
> So _xdg_mime_magic_lookup_data() is never called, i. e. > I can't see, how recent change(s) would effect mime-type > detection for XSL files. GnomeVFS uses xdg_mime_get_mime_type_for_data internally. Feel free to check it out and overwrite xdgmimemagic.c with that from xdgmime, or apply [1]. [1] http://mail.gnome.org/archives/gnome-vfs-list/2006-February/msg00077.html
Created attachment 4771 [details] XSLT Stylesheet (+XML,+ DTD) for testing "shared-mime-info"
Hmmmh... HEAD of "gnome-vfs" requires at least version "2.9.3" of "glib" which I would need to check out from CVS first ... I must admit that tests have become much more complex than I had expected in the beginning. Hope that nobody is mind, if I suspend further tests at least until I have set up either a development/ sandbox environment for building GNOME (entirely) from CVS or until "gnome-2.14" has been released. Furthermore I still do not think that recent changes will have any effect on mozilla/firefox browsers that are based on <= 1.7 branches, because mozilla (ExternalHelperApp) does not provide the actual file (contents) to gnome-vfs but only the extension. Maybe someone with an up-to-date GNOME development environment could check out the example files that I have attached using latest "gnome-vfs"/"share-mime-info" and firefox (<= 1.0.7). Cheers and thanks, Axel
> If I would build and install share-mime-info AND gnome-vfs > from CVS (HEAD) or wait for gnome-2.14 to be released > -- which will include the changes -- the mime-type that > would be reported for XSL files would be "application/xml", > because of the "content sniffing match" having higher priority > than the "file extension match". This is and will never be the case. Sorry if there were any misunderstandings due to the long time this bug report was open. All I'm claiming is that Mozilla is correctly associated with both XML and XSLT files, because it flags that it supports XML files, and our new sniffing code ensures that for ambiguous sniffs and unambiguous extensions the extension wins. I fail to see what your specific problem is. Is Firefox not listed in the "Open With..." menu of your XSLT files?
Chris, read again the first comments in this bug, in particular follow the given links.
> This is and will never be the case. Sorry if there were any misunderstandings > due to the long time this bug report was open. All I'm claiming is that Mozilla > is correctly associated with both XML and XSLT files, because it flags that it > supports XML files, and our new sniffing code ensures that for ambiguous sniffs > and unambiguous extensions the extension wins. I fail to see what your specific > problem is. > Is Firefox not listed in the "Open With..." menu of your XSLT files? Obviously there are a LOT of misunderstandings here ... My problem and the "bug" that was originally filed here is NOT about a wrong mime-type that nautilus (gnome-vfs) detects/displays for XSL files. The simple workaround for this would be to (manually) associate firefox not only to "text/xml" and/or "application/xml" but also to "text/x-xslt" and/or "application/xslt+xml" using nautilus' "Open With ..." settings. The REAL problem is that mozilla/firefox uses a (deprecated) function of libgnomevfs-2.0 (gnome_vfs_mime_type_from_name) to detect the mime-type for LOCALLY stored XSL files by passing just the extension (.xsl) as the filename. /* You can use my attached example files to produce the error with firefox 1.0.7 */ So no matter what changes are applied to the "content sniffing" code in gnome-vfs/xdgmime this will ALWAYS report the mime-type that is determined by GLOB-mathing. I think that the following solutions are possible * Wait until mozilla has changed the way it determines mime-types for locally stored (XSL) files * Change the mime-type for "*.xls/*.xslt" in "shared-mime-info" to "application/xml" (which was the original request) * Use my "mimeTypes.rdf" workaround. Hope that things have become a little more clear now. Axel
Thanks for your terse and clear summary of the problem Axel, and for all your efforts :). Marking as FIXED since we can't do anything about Mozilla's invocation of deprecated API. Sorry for all the bugspam and inconvenience.
Did I miss something, or could it be fixed by simply changing what the mime database contains as a mime type for *.xsl files? By putting the more generic text/xml (or application/xml) instead of the application/xsl+xml (which implies that it's an XSLT 2.0 file btw)
> Did I miss something, or could it be fixed by simply changing what the mime > database contains as a mime type for *.xsl files? By putting the more generic > text/xml (or application/xml) instead of the application/xsl+xml (which implies > that it's an XSLT 2.0 file btw) YES! It is that simple! Axel
I am a Mozilla upstream developer. Please see my comment 6. Please also note that even IF we fix the gnome-vfs call, this problem still exists because of comment 6. Fedora has fixed this issue in its version of Firefox and this is still a problem with shared-mime-info. Reopen.
Great! So this bug will run through a CLOSE/REOPEN cycle until end of time ... I really thought that the open source community is much more interested in cooperation and in working on solutions than in blaming others and in suspending simple changes due to obscure (standard compliance) arguments. Why not simply change the mime-type for .xsl/.xslt files to "application/xml" for now and think about, how XSLT 2.0 documents can be detected by content sniffing (in the future)? /* This might require changes/contributions to the RFC. * See: http://www.w3.org/TR/xslt20/#media-type-registration */ Assuming that shared-mime-info/gnome-vfs will be able to distinct between XSLT 1.0 and XSLT 2.0 (by content sniffing), why not immediately change the mozilla interface to gnome-vfs from calling a deprecated function using a "mutilated" argument (just the extension) to calling an up-to-date interface and providing as much information (the full path) as possible? Axel
As there's no separate namepsace for XSLT 2.0, it looks a bit ugly. Here are the changed I made to the application, let me know if there's any problems with it. 2007-02-05 Bastien Nocera <hadess@hadess.net> * freedesktop.org.xml.in: application/xslt+xml is reserved for XSLT 2.0 style-sheets, which we cannot detect because we don't read attributes, just namespaces. So remove *.xsl and *.xslt as application/xslt+xml globs, and add those to application/xml (the recommended mime-type for XSLT version 1.0) Leave application/xslt+xml present as a sub-class of application/xml to avoid breaking already existing program associations (Closes: #2928)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.