[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Re: XPath incompatibilities

Subject: RE: Re: XPath incompatibilities
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Wed, 2 Jan 2002 10:02:54 -0000
xpath max operator
> > 10. In XPath 1.0, the < and > operators, when applied to two
> > strings, attempted to convert both the strings to numbers and then
> > made a numeric comparison between the results. In XPath 2.0, subject
> > to resolution of an open issue, it is proposed that these operators
> > should perform a lexicographic comparison using the default
> > collating sequence.
> > ----------------------------------------
> >
> > I would prefer 1.0 and to have another operator for a lexicographic
> > comparison.
> I think that I agree. I'm having trouble working out what happens if,
> in a schema-less document, you have something like:
>   <foo min="3" max="15" />
> and want to check:
>   @min < @max
> I think that the values of the two nodes are converted to strings
> (although it's not exactly clear, given that the typed value of an
> attribute in a schema-less document is an empty sequence, and Section
> 2.6.1 of the XPath 2.0 WD (point 3) states that if either operand is a
> node, its typed value is taken, and if it's an empty sequence then the
> comparison returns an empty sequence; but then point 4 says that if
> they're untyped simple values then they're converted to strings, so I
> guess that's the case...)

I think we still have some work to do on schema-less documents and untyped
nodes. The general principle is that if you supply an untyped node as an
operand or argument where a particular type is expected, then the system
tries to convert it to that type; but this doesn't work where the operator
is polymorphic. Certainly one of the possibilities is that we try to define
the rules for @min<@max (i.e. a comparison between two untyped nodes) so
that attempts a conversion to numbers rather than to strings. (Another
option that's on the table is that we never interpret "<" as a lexicographic
comparison, forcing the user to use the compare() function instead, or
perhaps the new "lt" operator.).
> Anyway, if they *are* converted to strings, then obviously
> lexicographic comparison would give the result false, since '15' is
> lexicographically less than '3'.
> I think that there are lots and lots and lots of stylesheets that use
> the implicit conversion to numbers when doing comparisons, and that it
> would be very confusing to have lexicographic comparison.

My own guess is that most examples will do comparison against a numeric
literal, e.g. @max>3. If one of the operands is numeric, the comparison will
be numeric.
> I also think that it doesn't make sense for the greater-than and
> less-than operators to do lexicographic comparison if the other
> comparisons (= and !=) don't do lexicographic comparison (which they
> shouldn't).

I think the current intent, though it's not well described in the drafts, is
that "=" between two strings should do a comparison using the default
collating sequence. We might well decide that in XSLT, the "default default"
collating sequence should be Unicode codepoint comparison, which will be
compatible with XPath 1.0. The current XSLT 2.0 WD doesn't allow the user to
choose a different default collating sequence, but this facility is likely
to be added.
> > ========================================
> > 11. In XPath 1.0, functions and operators that compared strings (for
> > example, the = operator and the contains function) worked on the
> > basis of character-by-character equality of Unicode codepoints,
> > allowing Unicode normalization at the discretion of the implementor.
> > In XPath 2.0 (subject to resolution of open issues), these
> > comparisons are done using the default collating sequence. The
> > working group may define mechanisms allowing codepoint comparison to
> > be selected as the default collating sequence, but there is no such
> > mechanism in the current draft.
> > ----------------------------------------
Mike Kay

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.