Just a quick postscript to my earlier post for users of the archive.
At 2008-08-28 09:05 -0400, I wrote (modified):
I get the impression that you have copied a partial solution to your
problem because only one step is missing, yet the result evidence
you present seems not to match what the code you have would
produce. I'll just focus my answer on your code and not on your evidence.
At 2008-08-28 17:51 +0530, Pankaj Chaturvedi wrote:
<xsl:function name="my:reverse-string">
<xsl:param name="arg"/>
<xsl:sequence
select="replace(codepoints-to-string(string-to-codepoints($arg)),
'\[#x([0-9A-Za-z]+)\]', '#x$1;')"/>
</xsl:function>
Okay, the above does *not* put "[#xUUUU]" into the result tree as you contend.
It puts "UUUU;" into the result tree.
I gather you want "&#xUUUU;" in the serialized version of the result tree.
Using  is a typical approach to using output character maps
in serialization to get file results that are not possible using
default serialization.
Perhaps Tony Graham could correct me if I'm wrong here, but I've
stopped using  in my code and in my examples when presenting
this technique to my students because that is a Unicode private
character that *might* very well have meaning between two users who
are exchanging documents. Which means there might actually be user
data in the XML documents that includes such a private character
agreed upon between the two parties. XSLT serialization doesn't
distinguish the one character in two contexts when found in user data
or stylesheet-injected data of the output stream: it would translate
all such characters found.
The Unicode characters  through  have the semantic of
being a character that the sender and receiver can agree upon can be
of any meaning.
The Unicode characters  through  are specifically
"non-characters", which means they must not be used to represent
characters in a data stream between sender and receiver. This means
that two trading partners must not use them in XML documents, which
makes them available for XSLT users for this character mapping
technique without interfering with user data.
I agree using the private characters presents only an infinitesimally
small chance of corrupting user data since I'm not aware of people
actually using private characters for interchange. Nevertheless
using non-characters for this XSLT stylesheet character mapping seems
to me to be better guidance than using private-use characters.
I hope this is considered helpful.
. . . . . . . . . . . . Ken
--
Upcoming XSLT/XSL-FO hands-on courses: Wellington, NZ 2009-01
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--