Examining XSLT 2
22nd July 2005 · Last updated: 5th October 2016
I started work on a form that updates an XML file via XSL. It works using ASP on the server. The XML is displayed as HTML before and after it is updated. So far so good. Until I entered the Euro symbol '€'. The following error came up:
Unable to save character to 'ISO-8859-1' encoding.
This also WIPED THE XML FILE CLEAN! The file was completely blank. Clearly a serious issue if people are able to enter euros into the form.
I fixed it with the following ASP code. It replaces any euro characters with encoded versions. (I noted that a lot of ALT characters I tried entering into the form were automatically converted, but not euros.)
call replace (string,"€","€")
I then decided to look at the encoding to make sure it was UTF-8. It was then that I discovered the second page of the form had a <meta> tag that wasn't in the original XSL template! The tag was not only setting the encoding to UTF-16, but wasn't written as XHTML (no end slash) and used uppercase letters, as below:
<META http-equiv="Content-Type" content="text/html; charset=UTF-16">
Obviously this would make any XHTML page invalid. But what was going on? Where was the line coming from? It took me a while to find out. A clue was that the line only occured on the second page of my form. This was the only one with a <head> section. Turning to the W3C XSLT 1.0 specs, I discovered that:
If there is a HEAD element, then the html output method should add a META element immediately after the start-tag of the HEAD element specifying the character encoding actually used.
(Source)
What they are referring to there is the XSL output setting, which can be either 'xml', 'text' or 'html'. Yep, you guessed it - no 'xhtml'. Luckily this is part of the forthcoming XSLT 2.0 spec (currently in Draft form). I looked at the Draft and was impressed by the wealth of new features on their way. Features that will turn XSL into a powerful programming language almost like PHP. Already XSL can do a wide range of things including maths. (But are these things better done in ASP? Only then the code can't be viewed and processed, unlike XSL where it remains in XML.)