[xquery-talk] Problems with string testing in if
Sjur Nørstebø Moshagen
sjur.moshagen at kolumbus.fi
Tue Jun 1 11:50:46 PDT 2004
På 1. jun. 2004 kl. 10.16 skrev Michael Kay:
> 1. It would be a good idea to tell us which XQuery implementation you
> using. The drafts are still changing and different products implement
> different versions.
I'm using the XQuery engine of eXist (an XML native db)
(http://www.exist-db.org/), which is in itself a product in
development. I am using the latest snapshot of it. eXist has had XQuery
support since end of last year/beginning of this year: "The database
implements the current XQuery 1.0 working draft as of November, 2003,
with the exception of the XML schema related features." (from the
eXist has several interfaces. I have been using it as a webapp with
Cocoon support (cocoon.apache.org), utilising the XQueryGenerator for
Cocoon coming with eXist.
> 2. You haven't really explained what the value of the parameter to this
> function is. Can you give us a table that shows the input value
> and the result you are getting?
no_NO nor (in one case: when calling the script containing the
function from the Safari web browser)
no_NO test (in all other cases)
That is, ISO 639 to- and three-letter language codes, possibly extended
with country codes. The locale strings are normalised by the webapp to
lower case language code + underscore + uppercase country code,
irrespective of what the web browser sends (casing may vary, and often
a hyphen is used instead of underscore). This normalisation takes place
before the string is given to my function.
> 3. The code now looks correct to me. Both Jason and I supplied correct
> solutions to your coding error. I suspect the next bug is in the code
> calls this function.
The posting from Philippe Michiels confirms this. I have now tested the
function against other interfaces of eXist, and there it behaves as
expected. Thus it seems to be a bug in that specific XQuery interface.
> 4. Personally, I would code this using a lookup table: define an XML
> structure containing the input strings and output strings, and use an
> expression to access into this lookup table.
Thanks for the tip.
> 5. It's legitimate for different implementations to give you different
> answers if they use a different default collation. For example, some
> products might use a default collation that's case-blind (i.e. "no" =
Thanks for clarifying, it is not an issue here (see note above about
Thanks to all on the list for helping me and being patient with my
ignorance. I will contact the eXist developer with a bug report.
Sjur N. Moshagen
More information about the talk