RE: XPath 2.0 (Backwards Compatibility)

Thanks for pointing these out to the list.  
Some of the changes sound very disturbing indeed!


> -----Original Message-----
> From: Miloslav Nic [mailto:nicmila@xxxxxxxxxxxx]
> Sent: Friday, December 21, 2001 3:54 AM
> To: www-xpath-comments@xxxxxx
> Cc: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: 
> 
> 
> 
> 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.
> 
> ========================================
> 1.
> The rules for comparing a node-set to a boolean have changed. In XPath
> 1.0,
> 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
> 
> ========================================
> 2.
> The rules for converting a string to a boolean have changed, 
> so they are
> now
> 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.
> 
> 
> ========================================
> 
> 3.
> Additional numeric types have been introduced, with the effect that
> arithmetic
> may now be done as an integer, decimal, or single-precision 
> floating point
> calculation
> 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
> 4
> 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.
> 
> 
> ========================================
> 
> 4.
> 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.
> ========================================
> 
> 5.
> The rules for converting strings to numbers have changed. A 
> string that
> cannot
> 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
> on.
> 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.
> 
> 
> ========================================
> 6.
> 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
> converted
> to NaN.
> 
> ----------------------------------------
> 
> Do not have an opinion
> 
> ========================================
> 7.
> 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
> function
> 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
> children
> of an element, except for elements named item; with XPath 2.0 it will
> exclude
> text and comment nodes, because the condition ()!='item' is treated as
> false.
> 
> ----------------------------------------
> 
> WHY !???????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> I WANT 1.0 !!!!!!!!!!!!!!!!!
> 
> ========================================
> 8.
> In XPath 1.0, the sum of an empty node-set was zero. At XPath 
> 2.0, it is
> an empty
> sequence.
> 
> ----------------------------------------
> 
> I would prefer 1.0. I expect a number from sum .
> 
> ========================================
> 9.
> 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.
> 
> ========================================
> 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.
> 
> One of my common XSLT errors  is doing sorts based on numeric 
> values from
> the source and forgetting to set data-type
> 
> ========================================
> 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.
> 
> ----------------------------------------
> I do not have an opinion
> 
> ========================================
> 12.
> 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).
> ----------------------------------------
> WHY!!!!!!!!!!!!!!!!??????????????????????????????????/
> 
> Default conversions are very valuable for prototyping.
> 
> ========================================
> 13.
> In the XPath 1.0 data model, an element node had a namespace 
> node for each
> in-scope
> 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
> namespaces,
> 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
> nodes.
> 
> ----------------------------------------
> 
> 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@xxxxxxxxxxxx    </mail>
> <support> http://www.zvon.org  </support>
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 

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