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.

    

We think that there are two possible problems out here. 
  
1. Default namespace : 
The XQuery draft does not define any standard namespace like "err" which would be present by default. 
Such kind of default namespace would be useful.  A namespace defined in the draft: http://www.w3.org/2004/07/xqt-errors/
does not give details of any error codes to be used.
If a default namespace err is provided, then user would not have to define the namespace explicitly when he/she wishes to do some error handling. 

2. User defined namespaces and error codes.
The draft does not speak much about how a user can define his own namespace and error codes for errors. 
Is it possible to do this in XQuery ? It would be great to have some information on this aspect in the draft.

It would be beneficial to have a
function that removes trailing spaces from a string value (as in SQL's rtrim
function).
 
The reason is that fixed character RDBMS columns end up being mapped (per
the SQL 2003 spec) with trailing spaces where needed. That's nice, as it
fully exposes the available RDBMS information, but often these trailing
spaces have no real meaning for the application.

Mike Kay suggests use fn:normalize-space: 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Sep/0069.html

I don't think that the concept of normalized value applies to xs:date. 
There is no equivalent value to xs:date('2004-09-09-04:00') that uses 'Z'.
xs:date('2004-09-09-04:00') and xs:date('2004-09-09Z') are not equal.

In F&O 14.1.3, namespace-uri was changed to return an xs:anyURI instead 
of an xs:string. The sentence "If $arg is the empty sequence, the 
zero-length string is returned" is no longer valid. There may be other 
occurrences of this in the document where xs:string was changed to 
xs:anyURI.

In similar cases (11.2.3) the signature is xs:anyURI?.

So either:
fn:namespace-uri() as xs:anyURI?
fn:namespace-uri($arg as node()?) as xs:anyURI?

If $arg is the empty sequence, the empty sequence returned.

or:
fn:namespace-uri() as xs:anyURI
fn:namespace-uri($arg as node()?) as xs:anyURI

If $arg is the empty sequence, xs:anyURI("") is returned.

Mike Kay in http://lists.w3.org/Archives/Public/public-qt-comments/2004Sep/0044.html 
recommends we treat the empty string as a valid URI and return it.

The WGs agreed on 2004-09-28 that the zero-length string was a valid URI 
and that this comment could be closed with appropriate editorial changes.

Acknowledged.

According to F&O fn:error function must have the first parameter of
type xs:QName if it has any. For example, fn:error with only one
parameter has the following signature:

fn:error($error as xs:QName) as none

But '2.5.2 Handling Dynamic Errors' section of [XQuery] gives the 
following example of using fn:error

fn:error(fn:concat("Unexpected value ", fn:string($v)))

So, fn:error is called with the value of type xs:string. Sometimes, 
strings are castable to xs:QName, but it's not this case...

Would like a signature fn:error(xs:string)

The WGs agreed on 2004-09-28 to change the third and fourth signatures 
of fn:error to allow the empty sequence as the first argument with the semantic
that this indicated the QName err:FOER0000 - Unidentified error.

Two functions that I'd like to see added to xquery operators are:

  fn:match($input as xs:string?, $pattern as xs:string,   $flags as
  xs:string) as xs:string*
  fn:match($input as xs:string?, $pattern as xs:string) as xs:string*

The function fn:match supports capturing parentheses:

  fn:match("alpha/beta/gamma", "^(\w*).*(\w*)$") returns ("alpha",
  "gamma")

It the entire pattern does not match, then it returns the empty
sequence.

   fn:apply($funcname as xs:QName, $args as xs:anyType*) as xs:anyType*

The function fn:apply allows calling a function whose name may not be
known statically, for example based on input.

   let $f1 := 'fn:sum';
   let $call := <fn:sum><arg1>1</arg1><arg2>2</arg2></fn:sum>

   fn:apply($f1, (1, 2))
   fn:apply(fn:name($f1), $call/text())

The function fn:apply does not allow for arguments which are themselves
sequences, since nested sequences are not allowed in XQuery.

An alternative would be fn:call with versions for any arity:
fn:call($funcname as xs:QName) as xs:anyType*
fn:call($funcname as xs:QName, $arg1 as xs:anyType*) as xs:anyType*
fn:call($funcname as xs:QName, $arg1 as xs:anyType*, $arg2 as
xs:anyType*) as xs:anyType*
....

The WGs agreed on 2004-08-26 not to add the requested functionality.

Currently the casting table in Section 17.1 of Functions and Operators 
shows that xs:time can be cast into xs:dateTime. In Section 17.10, Rule 2 
states that this cast is done by merging the given time with the current 
date. But this rule makes the cast from xs:time to xs:dateTime 
nondeterministic. Every day it gives a different result. This kind of 
nondeterminism is very undesirable. It makes queries nonreproducible and 
it makes casting very difficult to test.

A user who attempts to cast an xs:time into an xs:dateTime is probably 
confused. It is dangerous to silently append the date on which the query 
happens to be running. It would be far better to make it an error to cast 
an xs:time into an xs:dateTime, and to provide an explicit two-operand 
constructor to construct an xs:dateTime from an xs:date and an xs:time. 
This would support the current functionality and more as well, would be 
safer, and would keep all our casts deterministic.

Proposal:
(1) In Section 17.1, change the table to show that xs:time is not castable 
into xs:dateTime.

(2) In Section 17.10, delete the rules that show how xs:time is cast into 
xs:dateTime.

(3) Introduce a new constructor function:
fn:dateTime($arg1 as xs:date, $arg2 as xs:time) as xs:dateTime
Note that both arguments are required (neither can be an empty sequence).
If a user wishes one of the arguments to be the current date or the 
current time, she can generate this argument by calling fn:current-date() 
or fn:current-time(). 

It has been noted that the proposed function can be defined as follows:
declare function fn:dateTime($arg1 as xs:date, $arg2 as xs:time) 
   as xs:dateTime 
   { xs:dateTime($arg1) + ($arg2 - xs:time('00:00:00')) }
Nevertheless, I believe that the proposed function should be built-in 
rather than user-defined. The namespace of the new function could be 
either fn: or xs: (following the convention of the other constructor 
functions).

The WGs agreed to make the recommended changes.

From the minutes of the 2004-03-16 minutes of the joint telecon on 
F&O issues [1]:
<<
5. Normative description of case mapping
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0979.html
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0037.html
ACTION HZ will propose.
ACTION MHK reply to Igor Herscht.
>>

     The problem that we were trying to point out in qt-2004Feb0979-01 [2] 
was that the first entry in the table in Section 1.2 of Unicode TR#21 [3] 
states, in part, "Only legacy implementations that cannot handle case 
mappings that increase string lengths use UnicodeData case mappings 
alone."  The penultimate paragraph of that section states, in part, "The 
full case mappings for Unicode characters are obtained by using the 
mappings from SpecialCasing plus the mappings from UnicodeData, excluding 
any latter mappings that would conflict."

     Similarly, the first paragraph of Section 2.3 of TR#21 [4] reads as 
follows.

<<
The following specify the default case conversion operations for Unicode 
strings, in the absence of tailoring. In each instance, there are two 
variants: simple case conversion and full case conversion. In the full 
case conversion, the context-dependent mappings mentioned above must be 
used.
>>

     All this seems to admit of (at least) two possible case mappings.  We 
believe that full case conversion was intended.

     I propose that in the first paragraph of each of Section 7.4.7 of 
F&O, we change "The precise mapping is determined using [Unicode Case 
Mappings]," to read "The precise mapping is the full case mapping variant 
of the toUpperCase operation defined in [Unicode Case Mappings],"  with an 
analogous change to 7.4.8.

Thanks,

Henry
[2] http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Mar/0096.html
[3] 
http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xpath-functions/issues.html#qt-2004Feb0979-01
[4] http://www.unicode.org/reports/tr21/tr21-5.html#Data
[5] 
http://www.unicode.org/reports/tr21/tr21-5.html#Case_Conversion_of_Strings
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

The WGs agreed to clarify the wording.  Since the reference to
TR#21 is outdated we agreed to change to refer to Unicode 4. Joint WGs telcon, May 25, 2004.

The comment is based on the entry in the Xquery document


> err:XQ0052 
> 
>   It is a dynamic error if the content of an element or attribute
>   constructor includes an atomic value that cannot be cast into a string,
>   such as a value of type xs:QName or xs:NOTATION. 

But it presumably applies to XPath and so XSLT as well, so I have not
prefixed the subject line with [Xquery]

I can see that there are problems with casting QNames due to prefix
bindings but NOTATION (and also ID, etc)  do not have this problem as
they are NCNames and don't have a prefix (or take part in namespace
processing) so the URI part of the QName should always be "".
as such there should be a trivial casting to string, namely taking the
name() = local-name().


schema part 1 says:
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#cNotation_Declarations

Schema Component: Notation Declaration 
{name} 
An NCName as defined by [XML-Namespaces]. 
   ^^

XML namespaces 1.0 was famously vague on this point but the wording is
clarified in 1.1:

http://www.w3.org/TR/2004/REC-xml-names11-20040204/#Conformance

    No attributes with a declared type of ID, IDREF(S), ENTITY(IES), or
    NOTATION contain any colons.


David

    

Resolved with the adoption of the 'triples' proposal: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jun/0090.html

(IBM-FO-044): The F&O document, section 17 (Casting) says "Constructor 
functions and cast expressions ... both convert a value to a given type 
with identical semantics and different syntax."  The XQuery language 
document agrees, in Section 3.12.5 (Constructor Functions): "The 
constructor function for type T .... has exactly the same semantics as a 
cast expression with target type T."

But this equivalence does not seem to extend to error messages. 

(a) The language document, Section 3.12.3 (Cast) says that a Cast 
expression can raise a type error (XQ0004 or XP0006), a dynamic error 
XQ0021 ("value cannot be cast to the required type"), or a dynamic error 
XQ0029 ("value does not satisfy facets of target type"). The language 
document does not list any errors for constructor functions.

(b) The F&O document, on the other hand, lists various casting-related 
error messages with names like "error in casting to decimal", "error in 
casting to integer", "invalid value for cast", etc. Some target types have 
specific error messages, but most do not. It is generally not specified 
which errors are dynamic and which are static.

The language document and the F&O document are not consistent in their 
handling of errors in casting, and it is not clear whether cast 
expressions and constructor functions return the same error messages. This 
latter property would be beneficial because it would allow implementations 
to transform cast expressions into constructor functions.

--Don Chamberlin

    

Minutes of San Jose meeting.  XQuery will align its error
messages with F&O.

(IBM-FO-043): Section 17 (Casting), paragraph 3 says "If an empty sequence 
is passed to a cast expression, an error is raised [invalid value for 
cast]." This is not correct. The XQuery syntax provides a way for the user 
to specify whether empty sequences are acceptable in a path expression. 
This feature was first added to the XQuery language document in the Nov. 
15, 2002 version, after discussions at the Query Working Group meeting at 
Chapel Hill, NC. The feature is described in the XQuery language document, 
Section 3.12.3 (Cast) as follows:

If the result of atomization is an empty sequence:
(a) If ? is specified after the target type, the result of the cast 
expression is an empty sequence.
(b) If ? is not specified after the target type, a type error is raised. 
[XQ0004] [XP0006]

This part of the F&O document should be made consistent with the language 
document.

--Don Chamberlin

    

The WGs agreed to accept the suggestion at the San Jose meeting.

Acknowledged.

F and O: 7.4.3 fn:substring()

The explanation of $startingLoc in 7.4.3 reads, "If $startingLoc is zero or
negative, the substring includes characters from the beginning of the
$sourceString." I find the meaning of the phrase "from the beginning of the
$sourceString" to be unclear and can't find any other reference to the
concept of negative character positions within a string.

Out-of-band communication on the www-ql list seems to indicate that the
concept of "imaginary character positions" preceding the physical start of
the string might be a useful way of explaining zero or negative $startingLoc
behaviour. I'd suggest the addition of this or a similar explanation to
7.4.3.

Howard

    

The WGs agreed to clarify the wording and add an example.  Joint
WGs telcon May 26, 2004

General 
Conformance	

Make explicit collation argument support an optional feature.

NOTE: This comment marks the end of our comments on the data model,
serialization, XQuery and F&O documents. We reserve the right to send
individual comments on issues that we may discover later.

    

General		
Conformance	

There are way too many functions (especially datetime and duration
functions). Please allow implementations to define function profiles as
part of a feature subsetting.

    

Section 17	Casting	
Editorial/Technical	

The casting rules from string to integer are unclear: How can I cast a
string "2.0" to and integer and get an error if I try to cast "2.8"?

    

The WGs ruled that the rules are clear and that no change is needed. Joint
WGs telcon May 26, 2004

Section 16.6 fn:default-collation	
Conformance	

Make support for this function optional dependent on whether explicit
collation support is provided. 

    

Section 15.4.4 fn:doc	
Technical	

Remove the sentence about not containing a fragment identifier. That
should be handled by the URI resolver. However please keep that the
result is always a document node or the empty sequence.

    

WGs agreed to remove the sentence and make other changes to the
wording to make it consistent. Joint WGs telcon, May 25, 2004.

Accepts the decision

Section 15.4.5 fn:collection	
Technical	

Not every XQuery implementations provides for collection support and
even if they do, they often have to provide an implementation specific
argument list and implementation specific semantics (stable or not
stable etc.). Since this leads to a high-degree of non-interoperable
behaviour, we recommend cutting this function.

    

The WGs decided not to remove the function

Accepts decision.  Hopes it will be made optional.

Section 15.4.4 fn:doc	
Editorial/Technical	

The following sentence (and remainder) should be removed and/or
rewritten: "The data resulting from the retrieval action is then parsed
as an XML document and a tree is constructed in accordance with the
[XQuery 1.0 and XPath 2.0 Data Model]. " The URI may point to a
pre-parsed document and the current wording implies that the function
needs to perform the parsing.

    

This has been overtaken by events.  Wording no longer exists in
this form.  Joint WGs telcon, May 25, 2004.

Accepts the decision

Section 15.1.14	fn:unordered
Editorial/Technical

Please use the following definition (and maybe change name to
fn:unorder()): Returns the input sequence in a non-deterministic order.

    

The WGs agreed to accept the suggested rewording.

Acknowledged.

Sections 10.2.2/14.1.2	
Technical	

Change result type to xs:NCName? of functions
fn:get-local-name-from-QName/fn:local-name. This is more precise and
will be more useful if passed to another function argument that expects
xs:NCName.

    

The WGs agreed to change the return type of
fn:get-local-name-from-QName as suggested but declined to change the
return type on fn:local-name.  Joint
WGs telcon May 26, 2004

Section 9.1.1 Limits and Precision	
Conformance	

We would like the minimal required range of years to be [0,9999].

    

The WGs declined to make the recommended changes.  Can be brought up
again during CR

Objected.

Section 1.6		
Technical	

We reiterate our comment submitted during our first last call review at
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0072.html
about the problem of the current requirement to preserve Timezones on
datetime values. 

    

Section 5 Constructor Functions 
Technical

Constructor function signatures should have the following signature:

pref:TYPE($arg as xdt:anyAtomicType?) as pref:TYPE?

See also comment MS-XQ-LC1-121
(http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0529.htm
l) 

    

The WGs agreed to accept the suggestion at the San Jose meeting.

Acknowledged.

Many languages provide a random number generator.  This can
be useful for testing; in my cases I wanted it as part of
generating SVG images.

Although it's possible to write a random number generator in
XQuery, it's hard to do with any efficiency, because a random()
function will always return the same random number (e.g. there's
no assignment to global or hidden variables).

Two obvious workarounds are (1) an external function, which isn't
always possible and isn't likely to be interoperable, and (2)
writing a function random(n) which returns the nth random
number in a series; this can then moderately easily be written
as a recursive function, with some care to avoid overflow.

I'd like to suggest either
(1) adding a random() function, possibly with an integer argument
    as outlined above, or,

(2) defining (in the future) a set of commonly needed external
    functions, and possibly adding a way to indicate that an
    external function may return different values on multiple
    invocations.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

    

Decided not to add the functionality requested at San Jose
meeting, 4/13/2004.

There's no easy way right now to check for the existance of a
local file except by trying to parse (and possibly validate) it
with document().

For example, consider using XML Query to generate an XHTML
Web page with embedded images.  One might not want to
include an image if the file isn't there, but there's no
way to test for a non-XML file in F&O today.

I suggest adding
    file-exists($fname as XS:string)

An alternative I shall propose in a separate comment is to
provide more access to an implementation's underlying
URI resolver library.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

    

Decided not to add the functionality requested at San Jose
meeting, 4/13/2004.

F&O currently provides limited access to URL resolution via
fn:document() (section 15.5.4).

There's no support for HTTP POST, nor for MIME parameters,
nor for query parameters.

There's also no clear indication of a result code, nor access
to language or media type information, if available.

If resolution fails, or if parsing the resulting resource
representation as XML fails, a fatal error is raised.

In the absence of a try/catch mechanism, having URI resulution
failure be a fatal error means you can't probe for the existence
of a document.

I propose that we supply a resolve-uri function, and that document() be
defined in terms of resolve-uri.  This adds significant functionality to
XQuery without a large additional cost, because implementations already
have such a resolver.

The following proposal is a little half-baked right now.  I'm looking for
the minimum that would be enough for XQ to build on later.  I'm worried
that if we neither support Web Services directly nor open up the URI
resolver it'll be really hard to add WSDL support later - and also that we
may have problems with internationalized queries and content negotiation.

If there's interest, I'm prepared to work on making this a more
robust proposal.  Leaving it for a future version would be a
satisfactory response for me if file-exists() and some form
of WSDL support are defined.

*


function resolve-uri($uri,$method,$http-params,$uri-params)
resolves the given URI using the given method (GET, HEAD, POST, etc) if
appropriate, and with the given parameters, e.g. as key/value pairs for POST.
The URI parameters are a sequence alternating between a string and an item
(ewwww, or is it better to use
    <param><name>xxx</name><value>yyy</value></param>,
since the efficiency loss is minimal compared to the amount of I/O involved?)
They might go after a ? separated by ; or & for an HTTP GET, e.g.
    http://www.example.com/search.cgi?q=frog
The optional Mime parameters are in the same format, and are most likely to be
an Accept list (e.g. to generate Accept: text/*, application/*) but can also be
used for content negotiation to support internationalisation.

resolve-uri returns a sequence:
    (1) a result code, as per HTTP and (compatibly) FTP; for a file: URL,
    the only likely codes are 20x OK, 40x fail, or maybe 30x redirected.
    A code starting with a 2 indicates success.

    (2) a string, the URI actually fetched, which may differ from that
    requested, for example because of symbolic links/shortcuts or because
    of HTTP redirects

    (3) the MIME Media type

    (4) the result, which in the case of error may be the empty sequence
    or may be an (X)HTML document describing the error.  In the case of
    multi-part responses, the result may be a sequence of document nodes.


Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

    

Decided not to add the functionality requested at San Jose
meeting, 4/13/2004.