- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 29 Dec 2009 14:59:46 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
OK, I figured out the FF issue. See John Resig's explanation here: http://ejohn.org/blog/tightened-local-file-security/ Basically, FF disallows locally loaded files from accessing resources (such as the XSLT) that are outside of the hierarchy of the HTML / XML file (so no "../foo" relative paths) to prevent downloaded HTML pages from actively trying to steal other information from a person's computer. If you want (I want!) you can override this behavior by going to FF's about:config and changing the security.fileuri.strict_origin_policy preference to "false" . rq25.xml should then render correctly locally. As far as I can tell, this closes all open issues around styling & XML & XSLTs and things like that. It also puts us in a better position to begin working towards unified styling, but I'll leave that for another day. Lee Andy Seaborne wrote: > > > On 29/12/2009 17:09, Lee Feigenbaum wrote: >> OK, I fixed the IE8 problem ... by making changes to a comment in the >> DTD. Don't ask me why. I don't understand DTDs. But rq25.xml renders >> correctly via http in IE8 now. > > Excellent! > >> >> So now Firefox and IE8 are OK from the Web. Chrome still doesn't quite >> work for me, but I think it might be due to plugins I have installed. >> Can someone else please check this? > > Chrome works for me. file: and http: > > Safari works for me too. file: and http: > >> >> I still can't get FF to render rq25.xml using the XSLT when served from >> a file:// URL though. > > Nor can I. For me, it does not recognize it's XML but I have been > putting that down to competition for file extensions on my machine. > >> >> Lee > > Andy > >
Received on Tuesday, 29 December 2009 20:00:27 UTC