RE: Last call comments on Xpath 2.0

A personal response from me: you will get an official response when the WG
has considered your comments. However, I would suggest that if you want the
WG to consider your suggestions seriously, you need to provide more detailed
semantics for the proposed functions, and rationale for their inclusion.

> fn:node-kind
> some sugar: what about cdata type test? can we add a 
> whitespace node type test?

What would a "cdata type test" do? We don't have CDATA nodes in the data
model.

What would a "whitespace node type test" do? This would seem to be a test on
the content of the node, not on its type. You can test whether the string
value of a node is all whitespace by using [normalize-space($node) eq ""].


> 
> why not add a lightweight schematron-like fn:assert() 
> function, probably nearthe the fn:trace section  
> fn:assert(test,pass element path, fail element path)
> ex.fn:assert(count(//fingers) = 4, 
> system/message/pass_element, system/message/fail_element) 
> note that this could be used in xacml type situations as well

I can't see how this would be any different from an if/then/else test, with
a call to error() in one of the branches?

Generally we are trying to reduce the size of the specifications rather than
add in more "nice to have" features.

> 
> as fn:trace is currently defined, why not have fn:log 
> equivelent function, might help some non-english speakers

How would you see the functionality of fn:log differing from fn:trace? It is
difficult to guess the semantics of your proposed function from its name
alone.

> 
> why not add fn:random as per latest exslt rand:random() 
> debate; integer * ranged-random-sequence(integer minValue, 
> integer maxValue[,integer numberOfItems := 1 [,double seed := 
> (double)current-time()]])

There are many, many functions that we could consider adding, for example
trigonometrical and square-root functions. We have to apply the test "does
this need to be in the core, or could it be provided in a third party
library?". Generally, we are trying to keep the size of the core library
small, and many people (both within the working group and outside) feel it
is much too big already.

Michael Kay

Received on Friday, 20 June 2003 13:28:33 UTC