[xquery-talk] Problems with string testing in if

[Sjur Nørstebø Moshagen]

På 1. jun. 2004 kl. 10.16 skrev Michael Kay:

> 1. It would be a good idea to tell us which XQuery implementation you 
> are
> 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 
site)

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 
> ($locale)
> and the result you are getting?

Sure.

Input:  Result:
------  -------
sme     test
sv_FI   test
sv      test
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)
en      test
smi     test

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 
> that
> 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 
> XPath
> 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" = 
> "NO").

Thanks for clarifying, it is not an issue here (see note above about 
normalisation).

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.

Best regards,
Sjur N. Moshagen