RE: F&O Nov 15 draft

David:
My apologies for not responding to your earlier mail.  I've had it in my
'to reply' folder for several months.  I've added comments inline to the
points you raised:

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.

[AM] This function is being rexamined and may go away.  If it does stay
we need to clearly spell out where the IDs come from.
 
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.

[AM]  We've discussed this and there is some support for it but not
(yet?) unanimous consent.  I think it would be an improvement.


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). 

[AM]  Good point!  I'll add some more examples.

  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.
[AM] Will do!

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.
[AM]  I'll think about it!

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 involving 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.
[AM] This is a comment that has come up with string comparisons as well.
The current position is that the user needs to strip the whitespace
before comparing.


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 XQuery and
XSLT
  documents where function definition is defined.
[AM]  We'll consider this.  Others have expressed this opinion. 


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).
[AM]  It's gone!


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.
[AM]  Removed from core.  Moved to Appendix C as example functions.

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.
[AM] The function now takes integer operands.
 

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


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
[AM]  Good point!

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).
[AM]  We decided not to define it as a second-order function.

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.
[AM] It's a good suggestion!

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)
[AM]  We hear you!

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.
[AM]  Semantics have changed in this draft.  Takes a sequence of values.


  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 to 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.

[AM]  We've done some work on the casting functions.  I think they are
easier to understand now.  

All the best, Ashok

-----Original Message-----
From: David Carlisle [mailto:davidc@nag.co.uk] 
Sent: Friday, November 22, 2002 6:14 AM
To: public-qt-comments@w3.org
Subject: F&O Nov 15 draft 



I sent some comments to this list on the last draft. I don't think I got
any acknowledgement (and none is shown in the archives)

http://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0050.html

Most of the comments seem to also apply to this draft...

David

_____________________________________________________________________
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 Friday, 22 November 2002 15:27:21 UTC