I was looking into xslt and started testing with the examples on w3schools.
However, when I save the xml and xsl in files and try opening them locally, chrome won't perform the xsl transform. It just shows a blank page.
I have added the<?xml-stylesheet type="text/xsl" href="style.xsl">
tag to the xml document, and firefox renders it as it is supposed to look. Also, if I look at the files through a web server, chrome displays the file as it is supposed to look.
Is it that chrome has a problem finding the stylesheet information when the link is local? Changing the href to file:///C:/xsl/style.xsl
didn't make any difference.
Update: This seems to be a side effect of a security-policy to not treat file:///* as same origin. This makes the following error appear in the console:
Unsafe attempt to load URL file:///C:/xsl-rpg/style.xsl from frame with URL file:///C:/xsl-rpg/data.xml. Domains, protocols and ports must match.
The short answer is "No, use one of the diverse set of browsers out there".
The reason this doesn't work is due to a security concern that Chrome has addressed in a controversial way[1][2][3][4], by blocking XML files from accessing local XSLT files in the same directory, while HTML files can access .CSS files in the same directory just fine.
Across the issues cited above, users have asked for a clearer error message (since the domains, protocols and ports do in fact match), or at least displaying the XML without the styling. Chrome developers have ignored these requests.
You can do this locally using Chrome's command line flags.
The specific flag is
--allow-file-access-from-files
On OS X: from Terminal.app run
/Applications/Google\ Chrome.app/contents/MacOS/Google\ Chrome --allow-file-access-from-files
On Windows: from the command prompt run
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe --allow-file-access-from-files
Note: You will probably have to quit Chrome if it is currently running otherwise Ch
It took a bit of deciphering on the Chrome Bug page - they are very keen on not explaining what the problem is, and why they chose breaking everyone rather than not breaking everyone.
Assume i have an XML file - somewhere - on my hard drive, e.g.:
And a malicious entity - somehow - managed to drop a malicious Xml file on my computer, e.g.:
Imagine TrojanVirusWorm.xml contains a stylesheet Processing Instruction (PI):
The attacker then instructs my browser to navigate to the locally saved
trojanVirusWorm.xml
file.Apparently there's a way that an XML file can read the contents of the XSD file (rather than being transformed by the XSD file):
I don't understand how an XML file can read a stylesheet file. But the Chrome team assures us that it's a danger, and that it cannot be solved.
Every other browser solved it. They solved it because it's not a problem.
If you want to stick to the OP, the answer is No (as others have pointed out) but one way to fix the problem is to run a simple webserver and open files via http in chrome. If you have python 2.x installed, you can run a webserver by typing:
Or in python 3.x :
and then open file using
http://localhost:8000/yourfile.xml
in chrome. Hopefully you just want to get your work done and its not a crucial thing to have to open file usingfile://
My workaround to see an xml according to an xsl file
Suppose we have an some_file.xml with headers:
https://some-site.com/Common.xsl
and place it next to thesome_file.xml
href="https://some-site.com/Common.xsl"
tohref="http://localhost:8001/Common.xsl"
python3 -m http.server 8001
http://localhost:8001/some_file.xml