XQuery 1.0 and XPath 2.0 Functions and Operators (16th August)

Some comments on the latest F & O draft.

David





2.6 xf:unique-ID
  "which may have been assigned by the user."
  It isn't clear here what or who "the user" is. (well it's clear if you
  know from elsewhere what this function does). In particular it isn't
  the user of _this function_. It would be better just to delete this
  phrase and just use the infoset property, as for other accessors.

 
4 Constructor Functions


  The semantics of the constructor function xs:TYP(item) are identical
  to the semantics of cast as xs:TYP (item).

  having introduced this functional syntax for casting (which is a good
  thing and potentially reduces the dependence on W3C-schema as one could
  imagine other namespaces providing types) one could consider dropping
  the "cast as" syntax, I see this is flagged as a possibility
  elsewhere, but wanted to comment that this would appear to be a useful
  simplification.


5.2.5 op:numeric-integer-divide

  If the quotient is not evenly divided by the divisor, then the
  quotient is the integer value obtained, ignoring any remainder that
  results from the division (that is, no rounding is performed). 

  I'm not sure that this is clear enough in the cases where one of the
  arguments is negative. You might want to specify the values of
   3 idiv  2
  -3 idiv  2
   3 idiv -2
  -3 idiv -2
   3 idiv  0

5.2.8 op:numeric-unary-minus
  You might want to clarify the behaviour on NaN  0 +0 and -0.

6.2 Equality and Comparison of Strings

 "it is not possible to guarantee that all strings in all XML documents
  are, in fact, normalized, or that they are normalized in the same
  manner."
 
 You might want to add a node tracking XML 1.1 which might (or might
 not) change the truth if this statement.

6.3.15 xf:matches

 Much improved functionality from previous versions, thanks.
 (Will need some time and experimentation to see if it really captures
 what is needed, but seems reasonable at first reading.)


8 Functions and Operators on Durations, Dates, and Times
  I wish I could add some constructive suggestions here.
  It is fairly horrible as it stands but its not clear which bits could
  easily be simplified. It's a shame though that given all this mass of
  functions invoving dates the one thing that is most often requested
  and currently requires shelling out to an extension language in all
  but the simplest cases will still require an extension language:
  Parsing locale-specific strings in instance documents into dates.
  "January 15th, 2002" etc.


11.1 Comparisons of base64Binary and hexBinary Values
  It would be more useful to compare after removing white space.
  that would mean that the encoded binary values were equal.


13.1.7 xf:deep-equal
  This function should not be in the core.
  Processing expectations require many variants of equality (ignoring,
  or not, comments, pis, white space, etc etc). It would be better to
  give this as an example of a user-defined function in the Xquer and XSLT
  documents where function definition is defined.


13.1.10 xf:copy
  This function should not be in the core (since it's not in XSLT).
  It ought be in an Xquery-specific function library.
  Also the name is bad as it corresponds to xsl:copy-of rather than
  xsl:copy.

  [Issue 60: What are the precise semantics of the copy() function?]
  in addition to the points raised in the node, the current spec only
  says that xf:copy produces a node with identity different from
  its argument. probably it should specify that it is a new node with
  unique identity that is
  xf:copy(x) is xf:copy(x)
  is false. Similarly it probably needs specifying that the node is not
  in a document so xf:root(xf:copy(x)) is the same as xf:copy(x).


13.2 xf:if-absent() and xf:if-empty()
   Neither of these functions should be in the core, for reasons stated
   in comments on earlier drafts.

14.1.1 op:to
  "Converts both its operands to integers "
   You might need to more fully specify what is returned if this
   conversion fails. -INF to INF for example.

 

14.2.5 xf:empty
  This function is unnecessary (duplicates casting to boolean) and confusingly uses 
  a different meany of "empty" to if-empty().


14.2.6 xf:exists
  This function is unnecessary (duplicates casting to boolean) but if it
  is kept the example should use xf:exists not  xf:empty

14.2.7 xf:distinct-nodes
or rather: [Issue 154: Should we define a second order distinct function?]
  Provision of higher order functions was clearly one of the main
  requirements coming from previous use of XPath. It remains a great
  disappointment that this requirement has not been met. rather than
  further complicate matters with special purpose syntax it may not be too
  late to really consider adding higher order functions to solve this
  issue (and simplify many other parts of the spec).


14.2.10 xf:remove
  This appears to be the same as $target[position() != $position]
  If it is the same it ought to be defined that way, if it isn't perhaps
  a note could be given explaining the difference.

14.3.1 xf:sequence-deep-equal
  I think the justification of this function (as of xf:deep-equal) is
  slight. It is also yet another part of the spec that could be
  simplified by higher order functions (in this case mapping an equality
  operator over a list)


14.4.2 xf:avg
  In this draft the meaning has been clarified as
  (computed as sum($srcval) div count($srcval)).
  but is that really intended?
  if the nodes contain data which are lists of integers
  <x>1 2</x>
  <x>3 4</x>
  count(x) is 2 but is sum(x) an error or 10 ?
  I'd have expected avg(x) to be 2.5 (10/4) in this case.


  similar comments apply to all the aggregate functions.
  They all use the phrase
   "Values that equal the empty sequence are discarded"
  whereas I would have expected them tou have used the standard list
  flattening procedure, which would naturally imply that empty sequence
  was discarded, but would also specify what to do in the case that the
  typed value was of list type.

16 Casting Functions
  This is clearer than in previous drafts but still fairly horrible.
  It still would seem preferable if the data model (and core
  XPath/Xquery) had a much reduced set of basic types, more like Xpath1+
  something for date/time. This would simplify the casting rules and the
  whole of the language. A W3C-schema-specific function library could then
  map the W3C-schema types to these core types.




_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Received on Tuesday, 27 August 2002 08:42:42 UTC