Delivery of XML on web browsers isn’t as popular as XML’s inventors originally hoped, but it’s still useful. It’s easy to add a standardized processing instruction to your XML that points at an XSLT stylesheet that converts your XML to HTML, and then when you open the XML file in your browser, you see the result. When you need a rendered version of some XML to review, this can make it happen pretty quickly. (The W3C Recommendation Associating Style Sheets with XML documents is possibly their shortest; its author, James Clark, was always good for a high signal-to-noise ratio.)

I’ve done this with Firefox very often, and I’ve set up a system for a client who needed to let users preview XML documents without starting up specialized software by doing the same trick with Internet Explorer. (Their choice of browser, not mine.) Recently, though, I found that this didn’t work with Firefox 3.0. The stylesheet was ignored, and the error console told me that there was a “Security Error: Content at file:///c:/my/path/filename.xml may not load data from file:///c:/some/path/stylesheet.xsl”. I understand the general idea of not letting a browser allow one file to load another, but when they’re both local, I see a baby going out with the bathwater.

I had to look pretty hard to find the solution, and of all places, it turned out to be on a website dedicated to an open source model railroad control system. (It would have been great if a posting in the thread came from Clyde Coil, but none did.) According to to page 3 of a thread on Who can help on XSL-Stylesheets, you need to reset Firefox’s security.fileuri.strict_origin_policy setting to “false”. This worked for me, and I hope I’m not opening some gaping security hole. I’d hate to have to choose between good security and Firefox rendering of styled XML.

After downloading Google Chrome, this XSLT trick was the first thing I tried, with no luck. When I used chrome to open an XML file with a processing instruction that pointed to an XSLT stylesheet, as described by James’ brief W3C Recommendation, it showed nothing—pure blank space, not even the PCDATA from the file. Chrome’s clean interface made it difficult to find out how to View Source, but luckily Ctrl+U did it like it does in Firefox. When I tried this, it displayed a color coded version of the XML file, including comments… but with all processing instructions removed, so the standard way to associate stylesheets with arbitrary XML files won’t work.

If Chrome is more about being an application development platform than another grab at desktop dominance, then I hope that XSLT is eventually part of that application development picture. Maybe someday.

4 Comments

By John Cowan on September 9, 2008 11:16 AM

The Google Chrome team has been made aware of this issue. (That’s as much as I’m authorized to say.)

By Erik Hetzner on September 9, 2008 11:17 AM

I’ve been using FF3 to load XSLT for XML on the same origin server (with relative & absolute URIs) without problems. There is more info about this policy here: http://kb.mozillazine.org/Security.fileuri.strict_origin_policy It might work for you to use an HTTP URI for the stylesheet or to put the stylesheet in the same dir or a subdir that the XML is in.

By Bob DuCharme on September 9, 2008 11:42 AM

John: thanks, that gives me hope.

Erik: thanks, I will try that.

By Norm on September 10, 2008 6:47 PM

We do the same thing with XML and XSL for displaying the output of our build system. Sadly I ran into the same problem as you with Chrome (we had figured out the FF3 “work-around” a while ago). I really hope Google fixes this. Given the speed of Chrome I’m hoping that this transfers to their XSLT processing (we have very large XML files and some complicated XSL). Putting the stylesheet in the same dir didn’t work for me. I’m going to try serving up the stylesheet from HTTP now.