Subject: Re: [xsl] xsl on safari?|
From: Julian Reschke <julian.reschke@xxxxxx>
Date: Tue, 21 Jun 2011 09:40:17 +0200
I've been developing a small application that converts xml to xhtml (strict) in the browser using an xsl stylesheet. It works as intended in the latest versions of Firefox, Opera, IE, and Chrome on Windows 7, and also in Safari on an iPad and Firefox in Linux. It breaks in ways I can't figure out in Safari on MacOS and Windows. I could evade the problem by converting the xml to html on the server side, but surely it's better to solve the problem by learning what I'm doing wrong than to dodge it.
There's a sample (malfunctioning) file at http://aal.obdurodon.org/tales/a095.xml. It's well formed, and it even validates in<oXygen/> against its schema (available http://aal.obdurodon.org/tales/aa.rnc). When I copy the html output of the transformation from a non-Safari browser (using a development plugin that will show me the result) and submit it to the W3 validator, it passes. When I save it (the html output) to disk and open it in Safari, it opens without error. When I open the xml directly from disk in Safari (with the xsl in the same directory), it generates the same error as I get when I retrieve the file from the web server. When I do that with the other browsers, they perform the transformation and render the html.
The file is one of a set that use the same schema and the same xsl; there's a list of other files at http://aal.obdurodon.org. Some are rendered properly in Safari; others break. The error messages are varied and not helpful (the following are from different documents in the set; the remaining 9 files in the set are rendered correctly):
error on line 1 at column 23: Extra content at the end of the document error on line 1 at column 1: Document is empty error on line 29 at column 16: attributes construct error error on line 44 at column 82: expected '>' error on line 23 at column 156: Opening and ending tag mismatch: p line 0 and sup
The files are UTF-8, which is the default Charset setting for my http server (although since I get the same behavior opening the file from local disk space, that would seem to take the server out of the equation). The file is UTF-8 and I've set UTF-8 as the default encoding in Safari (although I can't ask other users to do that, so it wouldn't be an adequate solution even if it worked).
My usual experience is that problems like this are most often user error, so I don't want to blame Safari for what may well be my mistake. On the other hand, I'm completely unable to think of how this error might arise only in Safari (and only on MacOS and Windows; Safari on iOS renders the files without a peep) when all of the other diagnostics don't seem to find a problem. Can anyone advise? ...