RE: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0

Subject: RE: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
From: "Michael Kay" <mhkay@xxxxxxxxxxxx>
Date: Thu, 6 Sep 2001 12:55:35 +0100
> > Incidentally, I'd encourage as much comment as possible on
> > this document
> > from the XSLT user community.
> Section 10 doesn't seem much of an advance on what we have today?
>   Is this the right document to look for grouping answers?

No, grouping is going to be handled at the XSLT/XQuery level, not in XPath
itself. The reason for this is that the XPath data model isn't going to
support sets of sets as a data type.
> For 11.4, I can't say I understand the collation idea,a simple
> example might have helped.

A collation is an algorithm for deciding whether two strings are equal, and
if not, for deciding which of them should precede the other. So for example
the collation called "caseless-German" might decide that "FLUSS" and "Fluß"
are equal. The thinking (based partly on SQL experience) is that the XPath
language specification should allow you to refer to a collation by name, but
that the facilities for creating/defining a collation should be left to the
implementer.  One reason for this is that some platforms (e.g. Windows,
Java, SQL databases) already contain such facilities, so you should be able
to refer simply to a collation that has already been predefined in your
particular environment.
> In this area, the problems associated with 'I want the next
> in the *sorted* order (not document order) appear not to be addressed.

The basic idea of having sequences in the data model rather than sets is
that the result of sorting a node-set can be assigned to a variable,
something which isn't possible in XSLT 1.0. There are then mechanisms for
iterating over a sequence or indexing into it.

> Unsure if xf:value-distinct does this or not, it appears to work on
> 'sequences' (which I guess includes node-sets?), and determines
> uniqueness by element content? Given an example
> <cat>
>   <head>...</head>
>   <content>... </content>
>   <other elements ....
> </cat>
> as the 'sequence' would it sort on the concat of head, content etc,
> or is that what the optional 'collation' is for?
Not really. The collation is for sorting strings. Deriving a string to act
as the sort key of a node, when sorting nodes, is a different problem.

Mike Kay

 XSL-List info and archive:

Current Thread