- From: David Carlisle <davidc@nag.co.uk>
- Date: Tue, 4 Sep 2001 18:15:54 +0100
- To: www-xml-query-comments@w3.org
Some comments on the document
David
===============================
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
implementation-dependent.
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.
2.6.1.3 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 2.6.2.3
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").
^
COMBINING CIRCUMFLEX 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 < etc, and the string
'Jérôme'
as used in this example should be a string of length 15 characters
that would appear in XML as
'Jéro&#x0302;me'
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.
4.1.3.3 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"?
4.3.1.3 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
Crikey:-)
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
fun).
===============================
_____________________________________________________________________
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