Subject: Re: [xsl] Printing CDATA from feed as HTML|
From: "Colin Adams" <colinpauladams@xxxxxxxxxxxxxx>
Date: Fri, 13 Jun 2008 10:11:16 +0100
2008/6/13 Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>: >>>>>> "Colin" == Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx> writes: > Hm. Maybe not. > > There is a portability problem here, in that there is a dependency > upon the Unicode encoding form used by the implementation. > > For instance, Gestalt currently uses UTF-8, so you need to specify: > > data:application.xml; charset=UTF-8 > > but I am currently re-engineering it to use UTF-32 (amongst other > changes), and so there is a problem. > > Now the implementation would be able to supply the actual encoding > using a higher level protocol (something internal to the > implementation of fn:doc()). You then have a clash between the > labelled encoding, and the encoding supplied by the higher level > protocol. Actually, I'm talking nonsense there. The higher level protocol IS the charset as supplied (or defaulted) by the data URI. The parameter won't include an XML declaration, so there isn't a labelling conflict. There IS a (potential) conflict between the implementation's Unicode encoding form and the charset on the data URI, so I wasn't talking complete nonsense - the portability problem is real. The solution is for the implementation of the data URI to silently override the supplied encoding. I'm not sure if that is legitimate or not. I suppose you can just say that it's an even higher level protocol. I wish I hadn't started this thread spinoff!