W3C home > Mailing lists > Public > www-xml-query-comments@w3.org > September 2001

Comments on http://www.w3.org/TR/2001/WD-xquery-operators-20010827

From: David Carlisle <davidc@nag.co.uk>
Date: Tue, 4 Sep 2001 18:15:54 +0100
Message-Id: <200109041715.SAA30728@penguin.nag.co.uk>
To: www-xml-query-comments@w3.org

Some comments on the document


  1.2 Notations
   Each function's signature is presented in a form like this:
   function-name(parameter-type parameter-name ... ) => return-type 

Having the type info in the signature appears to mean that the
following Parameters section is redundant in each case, and could be
removed. (Presumably this would just be a stylesheet change?)

  2.3 Numeric Constructors
  , if it conatains 

  10.2.6 xf:node-before
  If the nodes identified by the values of the two
  arguments are from different documents, the result is

XPath (at 1.0 at least) says that document order between nodes is
implementation dependent, but then functions relying on that ordering
have defined behaviour. As written here it would be allowed for xf:node-before
to to _always_ return true (or false, or a random boolean) if the
arguments came from different documents. 
Thus I think the quoted sentence should be deleted. (same occurs in
other places, eg 10.2.7).
The behaviour of the functions should be defined given an ordered set of
nodes. It's just that the ordering of nodes between documents (and
between attributes) is implementation defined.

  2.4 Operators on Numeric Values
  Issue 105.

Compatibility with XPath 1.0 div would be important to keep. Semantics

  Returns the largest (closest to positive infinity) number that is
  not greater than the value of $srcvaland that is an integer.
Perhaps this is a stylesheet issue? The space is missing in
other similar places, eg in

  3.3.1 xf:string
This is described as "This constructor is correctly perceived as a
"no-op", but is included for the sake of orthogonality." but the
examples show it not as a no-op but as a unicode normalizer,
combining o with the following Circumflex. Also typo in the name:

     U+0302, called "Combining Curcumflex Accent"). 

The examples (as noted in issue 106) appear to be confused about XML
character references. I believe the document should uniformly give
examples in XPath syntax that is _not_ XML encoded. Thus < should be
shown as < not &lt; etc, and the string
as used in this example should be a string of length 15 characters
that would appear in XML as
XPaths appearing an XML documents may of course use XML character
references _everywhere_ including the names of functions: they should
all be sorted out by an XML parser before the XPath engine sees them.
Conversely if XPath is being used in a non-XML context I wouldn't
expect XML character or entity references to be recognised at all.

  3.3.2 xf:normalizedString
Why are #D and #9 not allowed in the argument to this?
(I suppose the question ought to be why are they not in the lexical
space of the Schema analogue of this).

  3.4 Equality and Comparison of Strings

  A user who wishes to preserve the XPath 1.0 semantics of " < " and "
  > " can define a collation that converts each string to a number and
  then compares them numerically.

One hopes this will be the default XSLT setup?

  3.4.1 xf:codepoint-compare
Rather than return -1/0/1  it might be nicer
to have explicit less-than, equal and greater-than functions. 

  3.5 Functions on String Values
The table says there is a function xf:normalize but it appears later
as the (better) name 3.5.14 xf:normalize-unicode

  3.5.21 xf:replace
Yes please.

  3.5.18 xf:string-pad-beginning
This function (and the next) seem to be less useful than they could
be. The most common use of this is to pad some field to a fixed size,
in which case it would be more useful if the count argument specified
the desired _final_ size rather than the number of characters to add.
Otherwise you are _always_ going to be doing 
string-pad-begining(.,10 - string-length(.),' ')
Alternatively have a pad function that just produces a fixed
repetition of a specified character and let the user do the arothmetic
and concatenation with explicit concat. Semantics [of xf:boolean()]
  If the effective value of $srcval is "TRUE", 

really the uppercase version, even though the Xpath 1.0 conversion of
boolean true to a string produces "true"? Semantics [of xf:not()]
  Returns true if the value of $srcval is false and false if the value
  of $srcval is true. If the argument is the empty sequence the result
  is the empty sequence.

That's going to cause all kinds of compatibility problems isn't it?
perhaps: depends how sequences end up being reconciled with XPath 1.0
node sets I suppose.

  6.1 Constructors for QNames
These more or less consistently equate "no namespace" URI with an
empty sequence rather than empty string. (As noted in one of the
issues) This is likely to cause compatibility problems (unless all
functions coming from XPath 1.0 have suitable implicit coercions so the
difference has no effect).

  10.2.8 xf:copy
This I think would be a very confusing name given that in XSLT
xsl:copy is the _shallow_ copy. Couldn't you call it xf:copy-of.

  11.6.2 xf:avg
Is this really worth having? (given sum and div, it's hardly any extra
functionality, or even convenience.)

  11.6.5 xf:sum
  [Issue 67: Should duplicates be eliminated for count() and sum()?] 

I'd guess not, so long as XPath 1.0 constructs always construct the
natural document-order, duplicate free sequence that corresponds to
the Xpath 1.0 node-set construct. Thus duplicate removal should be in
the sequence construction not in the functions like sum().

  11.7.3 xf:filter
I'm not sure I understand the description of this function, but I
understand it enough to see that it does _not_ do what I'd expect a
"filter" to do. In languages that have such a construct I'd expect a
filter to take two arguments, a list of type x and a function from x
to boolean, and produce the filtered list consisting of those elements
for which the function was true.


  12 Casting Functions
This section is I fear an indication of just how much more
complicated and less intuitive XPath becomes when you throw in the XML
Schema types. I suppose it's progress, although for many of the types 
(ENTITIES etc,) it's hard to think of any real use for XPath functions
manipulating the data with these typed values as opposed to XPath 1.0
strings. (Other types such as dates etc clearly are a big win even if
complicated, handling date comparisons in Xpath 1.0 isn't a lot of


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, 4 September 2001 13:16:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:13 UTC