XML Query Last Call Comments on xpath-functions

X(n,}? matches X, at least n times

Would it not be X{n,}? ...
(i.e. a left curly bracket instead of a left round
bracket)

STATUS:  Fixed


    

Section 15.4.4 fn:doc	
Editorial	

Make the return type bold as the type is defined in the formal semantics
(the type is potentially found in the static document map context).

RATIONALE:  The return type is bold only if the type of the return
depends on the type of the arguments.  Not the case here.

    

SECTION Status

The bullet reading "The rules for converting numbers to strings have 
be amplified..." has a typo (change "be" to "been").


- Steve B.

STATUS:  Overtaken by events.

    

Throughout F&O, accommodate is misspelled; it has two m's.

Thanks,
Priscilla

STATUS:  Editorial. Fixed.

    

In the new spec, 0E0.0 is used in several places where it should be 
0.0E0. For example, see the substring examples (7.4.3.1).

--Sarah

STATUS:  Editorial.  Will fix as needed.

    

In section 7.1, the second note has the following sentence:
   "In functions that involve character counting [...] what is counted
   is the of XML characters [...]"
It seems to me that the word "number" is missing

Alberto

STATUS:  Editorial.  Fixed.

    

The XQuery function fn:doc() retrieves a document using an xs:anyURI. 
If the URI happens to be a URL such as http://www.xxx.yyy/sample.xml 
it is possible that the retrieval of the document requires user 
authentication in which case user credentials must be provided. 
This should be implementation-dependent. I would suggest that the 
documentation/spec indicate that user authentication is implementation 
dependent for functions where the user authentication may be required. 

The joint WGs decided on 2/28/2005 that no change was required.

I noticed some incompatibility between the name "local-name"
and the JAXP (Java) method names getLocalPart vs getLocalName.

The F&O method local-name-from-QName corresponds to the
JAXP methods QName.getLocalPart.

I think the phrase "local-part" is more precise, since it doesn't
make sense to get the "local name" of a name - you get the
local *part* of a name.  Plus of course it's nice to have
consistency between the XQuery API and the Java API.

The fn:local-name corresponds to the DOM method getLocalName.
That makes sense: the local name of a node is
the local part of the QName of a node.

The joint WGs decided on 1/19/2005 not to make this change.

Now that the prefix is a component of a QName,
it seems there should be a fn:prefix-from-QName function,
with the obvious semantics.

It is not strictly needed, since it is possible to
portably implement prefix-from-QName by casting the
QName to an xs:string and then looking for a ':'.
However, fn:prefix-from-QName is the low-level
"extractor" function that logically belongs in
the standard fn namespace.

The joint WGs agreed on 1/19/2005 to add this function.

In the October 04 language specification op:to was changed to have 
optionally have empty operands:
"Each of the operands of the to operator is converted as though it was 
an argument of a function with the expected parameter type xs:integer?. 
If either operand is an empty sequence, or if the integer derived from 
the first operand is greater than the integer derived from the second 
operand, the result of the range expression is an empty sequence..."

Which means in F&O the signature
op:to($firstval as xs:integer, $lastval as xs:integer) as xs:integer*

should be:
op:to($firstval as xs:integer?, $lastval as xs:integer?) as xs:integer*

If you notice, none of the op: functions in the F&O allow the empty sequence as argument even though the corresponding operator does.  This is because the empty sequence argument to operators is handled at the language level and never makes it down to the function. 

XQuery and XPath operate against the notion of a dynamic context, where 
the concepts of current collection, and document set are knowns, yet 
there are no functions available for exposing those variables. As a 
person who pretty much lives XML database technology, I find that 
information incredibly important from an implementation standpoint, if 
only to minimize reliance on APIs such as the XML:DB API in order 
perform repository discovery.

Therefore I propose that the following functions be added that expose 
additional aspects of the dynamic context:

fn:default-collection() as xs:anyURI
Returns a URI to the default Collection.

fn:child-collections(xs:anyURI) as xs:anyURI*
Returns a sequence of URIs to for the specified URI. Return an empty 
sequence if there are none, or an error if the underlying store does not 
support this functionality.

fn:child-collections() as xs:anyURI*
Same as the child-collections(xs:anyURI) form, but executed against the 
default collection.

fn:collection-documents(xs:anyURI) as xs:anyURI*
Returns a sequence of URIs identifying the document resources that are 
associated with the specified collection URI. Return an empty sequence 
if there are none, or an error if the underlying store does not support 
this functionality.

fn:collection-documents() as xs:anyURI*
Same as the collection-documents(xs:anyURI) form, but executed against 
the default collection..
 

The joint WGs decided on 1/19/2005 not to make this change.

I wish to endorse the statements made by Gunther Schadow 
(See http://lists.w3.org/Archives/Public/public-qt-comments/2004Dec/0017.html). 
concerning the need to adopt the full Perl 5 regular expression syntax, 
rather than the subset endorsed by the W3C Standards Group.  XSLT2 has the potential to 
become an integral processor and compiler of extremely sophisticated 
content, and as such its requirements for regular expressions 
considerably exceeds the validation only aspects inherent within the XML 
Schema implementation. I would strongly endorse adopting the Perl 5 
regex standard, and at the very least (as per motion #2, making adoption 
of the full set optional for vendors).
 

The joint WGs decided on 1/19/2005 not to make this change.

Objected.

The draft does not seem to specify what to do if the base URI is not a
hierarchical URI (e.g. a urn: scheme URI).

I cannot think of any meaningful resolution here. Return the base URI?