RE: [xsl] first question to the list: contains

> Scott, thanks for the great explanation.  Though it's 
> disappointing (as I need to check for _any_ Japanese 
> character to make this test effective), at least it makes sense. 

Scott's explanation is correct: you can't distinguish between a character
represented natively, and the same character represented as an entity
reference. And in your application, you shouldn't, because you really don't
want to constrain the document creator/sender to use one form rather than
the other.

XSLT 2.0 has good facilities for this. There's a function
string-to-codepoints which allows you to convert a string into a sequence of
integers representing the Unicode codepoints; or you can use regular
expressions which include constructs to match particular character
categories - 12360 is in the Hiragana block which is matched by
\p{IsHiragana}.

Michael Kay
http://www.saxonica.com/