This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: <sort lang="sv"/> in Saxon


Hi Joerg,

> Actually, it is not explicitely mentioned that the language
> determines the collating sequence.

You're right that it doesn't say so explicitly, but it does say:

  "The following optional attributes on xsl:sort control how the list
   of sort keys are sorted..."

so you can reasonably assume that the value you put in the lang
attribute would have an effect on the collating sequence (as long as
the lang was supported by the processor, of course).

> Furthermore, the concept of "local collating sequence" is, without a
> reference to a defining standard, ill defined. After all, what's
> "local": The machine default setting, if such a thing even exists, a
> user dependent environment, an environment setup specifically for a
> certain transformation run?

It says 'system environment' so I imagine that it's whatever
environment is available to the XSLT processor in the location where
it's run. In other words "I don't know" ;) The 'system environment'
also has a role in the lang attribute of xsl:number.

(Personally I think it's a bad idea to use the system environment to
determine anything, since the majority of transformations tend to
happen on a server machine for delivery to a client that might have
very different system settings.)

> I'd rather like to have the wording "The processor should document
> how it obtains a language in absence of an explicit specified
> value." or something like that. At least it's not as fuzzy as "get
> it from the environment".

You should suggest it to xsl-editors@w3.org.

> Just another note: practically every reasonable built up environment
> knows how to sort according to the POSIX LANG=C locale. But there is
> no standardized way to tell a processor to use it (unless i missed
> the IANA code for it). Except by default, of course. Hmm.

Possibly there is scope here for extension functions that access
system information, so that you could use it?

>> (xsl:)lang, on the other hand, is indicating the language of the
>> sort values, which is a uniquely XSLT concept.
>
> Agreed. But then, as we are already running a big schema impact
> discussion, how does this kind of language specification relate to
> schema specified datatypes?

I think that the impact would be that:

 - xsl:sort/@lang and xsl:number/@lang would be described as
   being of type xs:language

 - you could then guarantee that:

   <xsl:sort lang="{cast as xs:language($foo)}" />

   would give a valid value for the lang attribute.

I don't know if you've looked at the XQuery/XPath Functions and
Operators document, but it has some pretty vague stuff about referring
to different collations to determine the behaviour of functions like
xf:compare (see Section 3.4) and (very peculiarly, in my opinion) for
xf:starts-with. I'm not exactly sure where they're going with that,
but speculating wildly perhaps they're intending something like:

<xsl:collation name="Swedish"
               lang="sv"
               ...? />

and then:

  xf:compare($string1, $string2, 'Swedish')

If so, then perhaps these collations could be used by xsl:sort as
well. For *real* sophistication, I'm sure Dimitre would agree that it
would be nice to have:

<xsl:collation name="Swedish"
               template="Swedish-sort"
               ...? />

so that you could write your own template to compare two values, used
by xf:compare() and xsl:sort.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]