Subject: Re: [xsl] Where is 'intersect' Operator Defined in XPath 3? From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 10 Aug 2022 09:15:06 -0000 |
> But mostly, it tells me that the editor of XSLT 3.0 was consistently > more careful to be explicit about corner cases than the editor of XSLT > 1.0. > Sometimes this results from including explicit text as an aid to the reader, sometimes because it is logically necessary. Consider normalize-space() as an example. This expands from 3 lines in 1.0 to 30 lines in 3.0 In 1.0 the specification reads: <quote> The normalize-space function returns the argument string with whitespace normalized by stripping leading and trailing whitespace and replacing sequences of whitespace characters by a single space. Whitespace characters are the same as those allowed by the S production in XML. If the argument is omitted, it defaults to the context node converted to a string, in other words the string-value of the context node. </quote> In 3.0 the normative part of the specification reads: <quote> If the value of $arg is the empty sequence, the function returns the zero-length string. </quote> <remark>XPath 1.0 relies on you knowing the general rules for conversion of supplied arguments to the required type. A specific rule becomes necessary in 2.0 because many functions adopt a different convention, where supplying an empty sequence causes an empty sequence to be returned</remark> <quoteThe function returns a string constructed by stripping leading and trailing whitespace from the value of $arg, and replacing sequences of one or more adjacent whitespace characters with a single space, #x20.</quote> <remark>Very similar to the 1.0 text, but note for example the replacement of "sequences of whitespace characters" with the rather more pendantic "sequences of one or more adjacent whitespace characters".</remark> <quote>The whitespace characters are defined in the metasymbol S (Production 3) of [Extensible Markup Language (XML) 1.0 (Fifth Edition)].</quote> <remark>Again: the 1.0 text with a little bit more precision</remark> <quote>If no argument is supplied, then $arg defaults to the string value (calculated using fn:string) of the context item (.). </quote> <remark>Very similar to the 1.0 text</remark> <quote>Error Conditions If no argument is supplied and the context item is absentDM31 then a dynamic error is raised: [err:XPDY0002]XP31. </quote> <remark>This is a new addition, because the error condition could not arise in XPath 1.0</remark> So, the normative text has expanded, on my reckoning, from 63 to 102 words, mainly in the interests of greater precision and clarity, partly dealing with conditions that could not arise in 1.0. The main part of the expansion from 3 lines to 30 is thus in the addition of material that is technically redundant: mainly examples and notes. Now it's an open question how much of such redundant explanatory material the specification should include. What I find hard to understand is where people (specifically Dimitre) complain at the same time that there is too much of such material, and too little. It's hard to find a balance that pleases all readers, but it ought to be possible to find a balance that pleases one - unless his desiderata are internally inconsistent. Michael Kay Saxonica
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Where is 'intersect' Oper, Wendell Piez wapiez@ | Thread | Re: [xsl] Where is 'intersect' Oper, Eliot Kimber eliot.k |
Re: [xsl] Where is 'intersect' Oper, Dimitre Novatchev dn | Date | Re: [xsl] Where is 'intersect' Oper, Eliot Kimber eliot.k |
Month |