Subject: [xsl] RE: XPath 2.0 (Backwards Compatibility) From: "McKeever, Marty" <marty.mckeever@xxxxxxxxxxxxxxxxx> Date: Fri, 21 Dec 2001 08:57:29 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] A paranoic XPath 2.0 ques, David Carlisle | Thread | RE: [xsl] SAXON Fatal Error UTF-8 s, Wolfgang Bogacz |
RE: [xsl] How can I avoid generatin, thomas | Date | RE: [xsl] SAXON Fatal Error UTF-8 s, Mike Ferrando |
Month |