W3C home > Mailing lists > Public > www-xpath-comments@w3.org > October to December 2001

[www-xpath-comments] <none>

From: Miloslav Nic <nicmila@systinet.com>
Date: Fri, 21 Dec 2001 03:54:26 -0500 (EST)
To: <www-xpath-comments@w3.org>
cc: <xsl-list@lists.mulberrytech.com>
Message-ID: <Pine.LNX.4.33.0112210951320.13700-100000@mail.idoox.com>

I have started to read XPath 2.0 spec and obviously started with :
D Backwards Compatibility with XPath 1.0 (Non-Normative)

and I was deeply disappointed. The proposed changes introduce
inconveniences which will diminish value of XSLT as a prototyping
language for text processing and it will make it less accessible to
novices experimenting with XML.

In my opinion, changes should be made only if there are really compelling
reasons for them.
These changes can break old stylesheets and they will in their majority
make  text processing more complicated.

Please, see below my first reactions on individual points.

The rules for comparing a node-set to a boolean have changed. In XPath
an expression such as $nodeset=true() was evaluated by converting the
node-set to a boolean and comparing the result: so this expression would
return true
if $nodeset was non-empty. In XPath 2.0, this expression is handled in
the same way as other comparisons between a sequence and a singleton: it
is true if
$nodeset contains at least one node whose typed value is true.

seems reasonable

The rules for converting a string to a boolean have changed, so they are
aligned with XML Schema. In XPath 2.0, the strings "0" and "false"
are treated as false, while in XPath 1.0, they were treated as true. All
other strings
are converted in the same way as XPath 1.0.


I would prefer the 1.0  way. It is a rule which can become dangerous doing
text processing.


Additional numeric types have been introduced, with the effect that
may now be done as an integer, decimal, or single-precision floating point
where previously it was always performed as double-precision floating
point. The most
notable difference (subject to resolution of an open issue) is that 10 div
is now an integer division, with the result 2, rather than a floating
point division
yielding 2.5.


I would prefer very strongly 1.0. Integer division as the default
behavior is unnatural.


The rules for converting numbers to strings have changed. These will
affect the
way numbers are displayed in the output of a stylesheet. The output format
depends on
the data type of the result: floating point values, for example, will be
displayed using
scientific notation. The result of a decimal calculation such as 1.5 + 3.5
will be displayed as 5.0, not 5 as previously. The general
rule is that the resulting string uses the canonical lexical
representation for the
data type as defined in XML Schema.


I would prefer very strongly 1.0. Using XSLT to format  non-scientific
texts, the default behavior would be
a nuisance.

The rules for converting strings to numbers have changed. A string that
be interpreted as a number now (subject to resolution of an open issue)
produces an
error, whereas in XPath 1.0 it produced the value NaN (not a number).


I would much prefer 1.0 . When processing an XML file, it can happen that
the source contains
some misspelling, or that it is just a draft document with some data
missing. To get a fast preview of
the data, I would just use a few very short templates to see what is going
If the proposed change is accepted, I would spend a minute writing
stylesheet and than I will have to spent  10 minutes to do error handling
just to see my document and then throw the stylesheet away.

The representation of special values such as Infinity has been aligned
with XML Schema.
Strings containing a leading plus sign, or numbers in scientific notation,
may now
be converted to ordinary numeric values, whereas in XPath 1.0 they were
to NaN.


Do not have an opinion

Many operations in XPath 2.0 produce an empty sequence as their result
when one of the arguments or operands is an empty sequence. With XPath
1.0, the result
of such an operation was typically an empty string or the numeric value
NaN. Examples include the numeric operators, and functions such as
substring and
name. Functions also produce an empty sequence when applied to an argument
for which no other value is defined; for example, applying the name
to a text node now produces the empty sequence. This means, for example,
that with
XPath 1.0 the expression node()[name()!='item'] would return all the
of an element, except for elements named item; with XPath 2.0 it will
text and comment nodes, because the condition ()!='item' is treated as


WHY !???????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!

I WANT 1.0 !!!!!!!!!!!!!!!!!

In XPath 1.0, the sum of an empty node-set was zero. At XPath 2.0, it is
an empty


I would prefer 1.0. I expect a number from sum .

In XPath 1.0, an equality comparison involving an element node was
performed by
comparing its string value, that is, the string obtained by concatenating
all its
text node descendants. In XPath 2.0, it is an error to use an element node
in such
a comparison unless it has simple content. However, because the = operator
tests whether any pair of items from the two operands are equal, this
error will generally
be masked, so a comparison such as PERSON='abc', where PERSON is
an element with one or more child elements, will now always return false.

I prefer 1.0, but could live with the change.

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

One of my common XSLT errors  is doing sorts based on numeric values from
the source and forgetting to set data-type

In XPath 1.0, functions and operators that compared strings (for example,
= operator and the contains function) worked on the basis of
character-by-character equality of Unicode codepoints, allowing Unicode
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.

I do not have an opinion

If an arithmetic operator is applied to an operand that is a sequence of
two or more nodes, at XPath 1.0 the numeric value of the first node in the
sequence was used. At XPath 2.0, this is an error. (The current XPath 2.0
specification does not invoke fallback conversion in this case).

Default conversions are very valuable for prototyping.

In the XPath 1.0 data model, an element node had a namespace node for each
namespace. The parent of the namespace node was the element node, and the
namespace nodes
for one element were distinct from those of any other element (as
revealed, for example,
using the union operator |). In XPath 2.0 (subject to resolution of open
issues) element nodes will still have namespace nodes for all the in-scope
but these namespace nodes will be shared by different elements in the same
document: that
is, there will be a many-to-many relationship between element nodes and
namespace nodes.
This will affect any code that attempts to find the parent or ancestors of
a namespace
node, or that tries to count namespace nodes or to form a union between
two sets of namespace


If it means that namespace::xxx/parent::* returns all elements from the
document sharing
the namespace, it sounds interesting

<firstName> Miloslav </firstName>
<surname>   Nic      </surname>

<mail>    nicmila@systinet.com    </mail>
<support> http://www.zvon.org  </support>
Received on Wednesday, 26 December 2001 12:51:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:42 UTC