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? 

The joint WGs decided on 2/28/2005 to change the semantics of this 
function to allow implementations more flexibility.

"For xs:float and xs:double arguments, if the argument is "NaN", "NaN"
is returned. 
Except for fn:abs(), for xs:float and xs:double arguments, if the
argument is positive or negative infinity, positive or negative
infinity is returned." 

Why not for xs:decimal too?

Neither of the NaN, -inf, +inf are valid xs:decimal values. And you do
not want to return an xs:double value for fn:abs() (or any other
function) if you pass in an xs:decimal...

On U.S. PC's it is possible to conceptualize a switch that has yes/no values
for whether implicit-timezone() and current-dateTime() automatically adjust
for Daylight Saving Time. Users often set this switch to "yes". Is this
something that needs to be specified or is it implementation defined?

Basically, the values of implicit-timezone() and current-dateTime() are
implementation-defined. In an ideal world, they would represent the time as
shown on the user's wristwatch. In a less ideal world, they are likely to
reflect the system clock of the server where the software is running. It's
likely that this system clock will be adjusted for summer time, but there's
no explicit recognition of the concept in the XPath specs - no recognition,
for example, that in some parts of the world 2004-10-31T12:00:00:00 minus
2004-10-30T12:00:00 was 25 hours.

I'm am confused as to what is supposed to happen if the argument to
fn:doc() includes a fragment-id.

On the one hand, the draft says the argument is an xs:anyURI, passed
as an xs:string, so it is legitimate to include a fragment-id.
On the other hand, the semantics is defined as a mapping of strings
onto DOCUMENT nodes, and a fragment-id cannot point to a document node
(though it might point to a document element).

But the way URIs are mapped onto document nodes is not specified. Does
this mean it is implementation-defined as to whether the fragment-id
is used, or is it an error to include one?

The argument to fn:doc is an anyURI (in the form of a xs:string)
that allows a fragment identifier.  We agreed to add words to
clarify this.

The mapping of xs:anyURIs to document nodes is implementation-defined
and is the function of the uri-resolver.

Acknowledged.

We seem to allow casting to xs:NOTATION now. If it indeed is an abstract
type, then we should not support a cast and should mark it as abstract
in the type hierarchy figure...

Agreed to make this change at the F2F mtg in Redwood Shores..

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.

The "err" namespace is intended for system-detected errors, not for
user-detected errors. There's no ban on users calling error() with codes in
the "err" namespace, but it's not something I think we should encourage -
users should define their own error codes in their own namespace.

Acknowledged.

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

The joint WGs discussed your request on November 9 and decided against adding
such a function on the grounds that it was not difficult for users to write such a function.
In fact, if someone would provide the definition of a function to trim trailing spaces
from a string we could add it to Appendix D -- Illustrative User-written functions.

Acknowledged.

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.

STATUS:  This comment was accepted at the Brisbane meeting on 1/19/2005.
See minutes.

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.

STATUS:  Moved to conformance discussion.

    

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.

STATUS:  Moved to conformance discussion.

    

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.

STATUS:  Moved to conformance discussion. 

    

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. 

STATUS:  After long discussion, the WGs decided on maintain the status quo
on timezone preservation.  See minutes of Brisbane meeting 1/19/2005.

    

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.

Unless there is a good reason not to, please provide a schema document
for the xmlns:xdt="http://www.w3.org/2003/11/xpath-datatypes"
namespace, containing at least the definitions for
xdt:yearMonthDuration and xdt:dayTimeDuration, to facilate their use
by schema authors.

I would recommend that such a schema document should appear both as a
normative appendix to one of the spec. documents _and_ as an
independent document at the namespace URI, i.e. at

 http://www.w3.org/2003/11/xpath-datatypes.xsd

The latter document should be governed by the W3C policy for
namespace-related documents, reference available on request.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

    

The WGs agreed on 2004-08-26 to accept Henry's suggestion.

F&O [9] Functions of Durations, Dates, and Times

The dateTime, date, and time component accessors are not very useful, as they
always return the values for Z (UTC) rather than for the implicit timezone or
some specified timezone. Thus for 12/31/2003 at 9am (Pacific) you get 2004
rather than 2003 as the year. This is because they are defined in terms of the
XML Schema canonical forms, which are always in UTC (if a timezone is present
at all).

Similarly, we find the description of the operation of the functions in
section 9.6 (adjusting to timezone) and hence their utility unclear, as results
are shown with strings, none of which is the result of casting a date or
dateTime to a string, as none is in canonical form. Given the nature of the
component accessors, it is unclear what the benefit of adjusting the timezone
might be.

Many of the date/time/duration-related functions and operators are of very
limited utility and add a great deal of implementation cost and user
confusion. Suggest removing all the functions in section 9.4, as the ISO8601
time formats are readily parsable as strings, perhaps replacing them with
functions to map dayTimeDuration and monthDayDurations to numeric
values. Suggest removing all the functions in section 9.6 as well as the
multiplication and division operators in section 9.5 as being of very marginal
utility for the cost. The net effect would be substantial reduction in the
number of functions that implementors must implement and that users must be
aware of, with no substantial loss of functionality. 

If the dateTime and time component accessors are kept, then please add a
parameter indicating which timezone the accessor should be applied to, or
specify that the accessor should be performed relative to the implicit
timezone, or specify that the component should be the value of the component in
the underlying value space. 

If the timezone adjustment values are kept, it might be appropriate to define
them as returning string values, or to define functions that will render
dateTime, time, or date values as string values relative to some timezone (the
underlying timezone component in the value space, the implicit timezone, or a
timezone given as a parameter to the function).

    

Date/time component Extraction functions work on localized values.

(IBM-FO-038): Section 15.2.1 (fn:deep-equal) has many problems. The text 
that begins "Return true if the two nodes have names that compare equal" 
does not match the code that follows it. It's not clear why the case 
dealing with document nodes is surrounded by comment delimiters. The code 
contains various syntax errors (if with no else, missing parens after 
"not", "return" used improperly, etc. Clearly nobody has ever tried to 
parse this code.

--Don Chamberlin
  

On May 4, 2004 we decided to accept wording suggested by Mike Kay.

(IBM-FO-036): Section 15.1.13 (fn:subsequence): This section says that 
$startingLoc has type xs:double. But in Sections 15.1.10 
(fn:insert-before) and 15.1.11 (fn:remove), the type of $location was 
xs:integer. What is the reason for this inconsistency?

--Don Chamberlin

    

The WGs decided not to make the suggested change at the Cambridge meeting.

(IBM-FO-034): Section 14.1.3 (fn:namespace-uri): Describes what happens if 
the argument is "an element or attribute node that has no QName". How 
could an element or attribute node not have a QName?

--Don Chamberlin

    

We discussed in Cannes and agreed to fix wording.

(IBM-FO-032): Sections 9.7.3 (op:subtract-dates) and 9.7.4 
(op:subtract-times) have "?" occurrence indicators in their signatures and 
state that their arguments may be the empty sequence. But the other op: 
functions in this section (such as 9.7.13, op:add-dayTimeDuration-to-time) 
do not have "?" occurrence indicators and do not accept empty sequences. 
What is the reason for this inconsistency?

--Don Chamberlin

    

Fixed in response to an earlier comment.

(IBM-FO-024): In Section 9.3, Comparison of Duration, Date, and Time 
Values, the last paragraph says "If the timezone part is (), the implicit 
timezone is used to adjust the normalized value as necessary." I am 
wondering why this rule is found only in the description of the comparison 
functions and not other functions that operate on dates and times. Section 
9.4 (Component Extraction Functions) does not state such a rule. Section 
9.7, which contains arithmetic functions on dates and times, says "If any 
argument ... does not contain an explicit timezone, then ... an implicit 
timezone ... is assumed to be present." This rule does not say anything 
about adjusting the normalized value. I find it confusing that the rule 
dealing with implicit timezones is stated in different and possibly 
conflicting ways in Sections 9.3 and 9.7, and missing in Section 9.4.

--Don Chamberlin

    

The WGs agreed accept Andrew Eisenberg's proposal: 
http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Sep/0058.html 
and close the comment.

Acknowledged.

I have been testing the example stylesheets in my XSLT Programmer's
Reference under XSLT 2.0. Three or four of the examples (so far) have failed
with the same error: concat() in XPath 2.0 requires the arguments to be
supplied as strings. The most common examples are things like:

 

<title><xsl:value-of select='concat("Chapter ", position())'/></title>

 

It doesn't fail under backwards compatibility mode, of course. But that's
not good enough, we want to encourage users to run in pure 2.0 mode whenever
possible.

 

It doesn't seem reasonable here to ask users to write string(position()).
How can we justify asking them to make such changes - where are the
benefits? 

 

It's not required in XQuery, whose equivalent construct is:

 

<title>Chapter {position()}</title>

 

If this can implicitly cast to string, why can't concat()?

 

Java has a general policy of strict typing, but it makes an exception for
the string concatenation operator, which casts its operands implicitly to
strings. In XPath, concat() is already special-cased by allowing a variable
number of arguments. 

 

I believe we should change the signature of concat() so its arguments are
defined as anyAtomicType, and are implicitly cast to strings.

 

Michael Kay 

    

The WGs agreed to make the suggested change.

Dear colleagues,

This note is to ensure that your last-call issues list includes a
question we raised already in our earlier review of the Functions and
Operators specification; in our notes on that spec of last 1 August,
it had item number 1.4 [1].  (I took an action to write you on this
account some time ago.  My apologies for the delay, but I venture
to hope that our concern will not come as a surprise to you.)

While we understand (even if we do not fully agree with) the reasoning
which has led you to make all of the functions for operations upon
URIs accept strings as arguments, we have not understood the reasoning
which leads you to require that they raise an error if they are given
an argument of type anyURI, and we respectfully suggest that you
ensure that these functions can be called upon arguments of type
anyURI without raising a type error, and that the results can where
appropriate conveniently be coerced into type anyURI.

The status quo would have the effect of discouraging the use of the
anyURI type and of encouraging users to lie to their processors by
typing values as strings instead of typing them, more accurately and
more usefully, as URIs.

with best regards,

-C. M. Sperberg-McQueen
 on behalf of the W3C XML Schema Working Group


[1]
http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e145

    

The WGs agreed to an anyURI to string promotion scheme. April 13,
2004 in the San Jose meeting.

(IBM-FO-020) Section 15.4, Functions and Operators that Generate 
Sequences: We need a function that takes an XPointer as its parameter, 
dereferences it, and returns the node referenced by the XPointer. Since 
this function has similarities to both fn:doc and fn:id, it should be 
defined in the same section as these functions. This function would 
satisfy XQuery Requirement 3.3.4, which requires support for references 
from one XML document to another.

--Don Chamberlin

    

The WGs considered this in Cannes and decided not to add this function.

(IBM-FO-019) Section 15, Functions and Operators on Sequences: There 
should be a "deep-distinct" function that eliminates duplicate items from 
sequences. Duplicate atomic values should be defined by the "eq" operator. 
Duplicate nodes should be defined by fn:deep-equal(). In the case of 
duplicate nodes, the node that is retained should be 
implementation-dependent. This function is needed by queries that need to 
perform grouping where the grouping-key is a node (for example, grouping 
by <address> that has subelements <street> and <city>, or grouping by 
<author> that has subelements <first-name> and <last-name>.)

--Don Chamberlin

    

The WGs agreed not to add the function as it would be too
fragile for order-by.  A better approach is to use constructed
compound keys. Joint WGs telcon, May 26, 2004.

(IBM-FO-018) Section 15, Functions and Operators on Sequences: There 
should be a "copy" function that returns an exact copy of its input 
sequence, with new node identities but preserving type annotations. 
Otherwise there is no way to make a copy of a node without wrapping it in 
a constructor, which the user may not wish to do.

--Don Chamberlin

    

The WGs agreed on 2004-10-20 that this issue should be postponed
and considered as a feature for the next version of XML Query.

(IBM-FO-017) Section 14.1.1, fn:name: Fifth paragraph says that "the value 
returned is an xs:string whose lexical form is an xs:QName."  But it does 
not tell us where this string comes from. Elsewhere, the F&O document 
tells us that there is no way to cast a QName into a string. This is an 
inconsistency in the document.

--Don Chamberlin

    

The WGs agreed to accept Michael Kay's "triples" proposal.  This addresses the issues raised.

Acknowledged.

(IBM-FO-015) Section 6.2, Operators on Numeric Values: Third paragraph 
says "Operands of type xdt:untypedAtomic are converted to xs:double, 
except for the arguments to op:numeric-integer-divide which are converted 
to xs:integer." Actually, these conversions are performed by the semantics 
of the arithmetic operators rather than by the underlying functions. The 
conversion is already done before op:numeric-whatever is called. 
xdt:untypedAtomic is not a numeric type and does not satisfy the 
signatures of these functions. The conversions are described in 
XPath/XQuery section 3.4 (Arithmetic Expressions) and should not be 
repeated here.

Similarly, Section 6.3, Comparison of Numeric Values: Claims "Arguments of 
type xdt:untypedAtomic are converted to xs:double". This is not correct. 
Value comparison operators convert arguments of type xdt:untypedAtomic to 
xs:string, not xs:double. In any case, the type xdt:untypedAtomic is not a 
numeric type and does not satisfy the signatures of the functions in this 
section. This conversion is described in XPath/XQuery Section 3.5.1 (Value 
Comparisons). Repeating it here is both redundant and incorrect.

Also, Section 6.4, Functions on Numeric Values: Says "If the argument is 
xdt:untypedAtomic it is converted to xs:double". This doesn't belong here. 
Type conversions of the arguments of numeric functions are handled in the 
XPath/XQuery document, Section 3.1.5 (Function Calls). The rules include 
atomization, XPath 1.0 compatibility mode, etc. The Functions and 
Operators document should only explain what a function does with an 
argument of the expected (numeric) type.

In summary, all references to arguments of type xdt:untypedAtomic should 
be deleted from Sections 6.2, 6.3, and 6.4. These semantics are covered 
elsewhere. Numeric functions are not a special case. They should only 
describe what they do with arguments that satisfy their signatures--i.e., 
numeric arguments.

--Don Chamberlin

    

The WGs agreed to make the suggested changes.

(IBM-FO-012) Section 5.1, Constructor Functions for Built-in Types: The 
return types for the xs:dateTime, xs:time, and xs:date functions are not 
valid SequenceTypes. We do not have tuple-types in the data model. In 
general, handling of timezones in dates and times needs to be clarified 
throughout the Data Model and F&O books. All our functions should be 
closed under the Data Model and should not return things that are not Data 
Model values (like "tuples").

--Don Chamberlin

    

The WGs agreed to change the constructor functions to return
single values of the appropriate type.
Joint WG telcon May 26, 2004

(IBM-FO-011) Section 4, The Trace Function: I suggest that the actual 
creation of a trace data set be made optional. Say that this function 
supports debugging of queries in a portable way, by allowing an 
implementation to optionally provide a data set containing a trace of 
execution. The only normative requirement for this function is that it 
returns its first argument. If an implementation chooses to provide a 
trace data set, the string values of the first and second arguments are 
directed to the trace data set. (Location, format, and ordering are 
implementation-dependent, as stated.) In effect, fn:trace becomes a 
function that systems can either implement or ignore without raising an 
error. 

--Don Chamberlin

    

The WGs adopted the suggestion to make the creation of the trace dataset optional.

(IBM-FO-010) Section 2, Accessors: We need functions to expose the 
dm:unparsed-entity-system-id() and dm:unparsed-entity-public-id() 
accessors of a document node. Otherwise, what are these dm: accessors good 
for?

--Don Chamberlin

STATUS:  Discussed in Cannes:
"Moved to datamodel issues for later discussion (clustered by Norm)"

    

(IBM-FO-008) Section 1.5.2, xdt:untypedAtomic: Delete "or a DTD". We do 
not support DTD validation.

--Don Chamberlin

    

The datamodel supports XML documents that are DTD validated.

(IBM-FO-006) Section 1.4, Type Hierarchy: The third table in this section 
contains an entry for "user-defined document types". But there is no such 
box in the type hierarchy diagram, and there is no such notion in XML 
Schema. This entry should be deleted.

--Don Chamberlin

    

Fixed in the current version of the F&O.

fn:base-uri() called without arguments returns base-uri property from static context.
But many users may think it returns property of context node like all other functions taking zero or one argument
[fn:name(), fn:local-name(), fn:namespace-uri(), fn:number(), fn:root() ]. This could lead to many hard to find errors.
I propose changing name of zero argument version of function to prevent confusion.
Maybe fn:static-base-uri() or fn:implicit-base-uri() ?

Best Regards,
Noe Michejda
7th Portal S.C.

    

The WGs adopted the suggestion to change the no-argument version of 
fn:base-uri to return the base-uri of the context item and add a function 
fn:static-base-uri to return the base-uri from the static context.

Build-in type xs:anyUri deserves better treatment in my opinion.

Currently it can be only compared with another xs:anyUri or casted to string.
But basically it is a string with additional restriction on structure (like pattern facet).
So xs:anyUri should be treated as derivation by restriction from xs:string by all XPath/XQuery rules.
This will allow to define function signatures using xs:anyUri and remove lexical checks from definitions
of functions.
Maybe it will be possible to change derivation diagram in XML Schema 1.1 and reference it instead
of 1.0 in XPath 2.0 / XQuery 1.0 ? This will be simpliest solution.
(and btw allow placing dayTimeDuration and yearMonthDuration in schema namespace)

Best Regards,
Noe Michejda
7th Portal S.C.

    

The WGs agreed to an anyURI to string promotion scheme. April 13,
2004 in the San Jose meeting.

SECTION 11.2: op:anyURI-equal

op:anyURI-equal simply compares the URI string, but it should also take into account the base-uri.

 For example,

given a base declaration 

 declare base-uri="http://www.foo.com"

 The expression 

 xs:anyURI("http://www.foo.com/boo") = xs:anyURI("boo") should be true.


- Steve B.
  

The Wgs discussed this on 3/16 and declined to make the change.

I propose that we rename the functions:

years-from-yearMonthDuration
months-from-yearMonthDuration
days-from-dayTimeDuration
hours-from-dayTimeDuration
minutes-from-dayTimeDuration
seconds-from-dayTimeDuration

to

years-from-duration
months-from-duration
days-from-duration
hours-from-duration
minutes-from-duration
seconds-from-duration

without changing their signatures.

Firstly, the new names are shorter, which is a good thing in itself.

Secondly, I think we should anticipate at some stage (in v3.0)
supporting these functions on all durations, not only on the subtypes.
This naming change will make it easier to extend the domain of the
functions in the future.

Michael Kay 

    

The WGs agreed to make the suggested changes.

In this case it would be consistent to change the definition of the
zero-argument base-uri() function in F+O so that if no base URI is
defined in the static context, an empty sequence is returned.
 
Michael Kay

STATUS:  We agreed to do this in Cannes.  
 
 
 -----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Don Chamberlin
Sent: 19 February 2004 00:55
To: Daniela Florescu
Cc: public-qt-comments@w3.org
Subject: Re: [XQuery] BEA_028




Dear Daniela, 
The following sentence has been added to XQuery Section 3.7.1: 
"If no Base URI is defined in the static context, the Base URIs of the
constructed and copied nodes are set to the empty sequence." 

Similiar sentences have been added to Sections 3.7.3.1 and 3.7.3.3. 

Please let us know whether you are satisfied with this resolution of
your issue. 
Regards,
--Don Chamberlin




Daniela Florescu <danielaf@bea.com> 
Sent by: public-qt-comments-request@w3.org 


02/15/2004 10:25 PM 


To
public-qt-comments@w3.org 

cc

Subject
[XQuery] BEA_028

	





XQuery: incomplete specification

Section 3.7.1 and 3.7.3 discuss the base-uri property of the new nodes
but does not say what should happen when
the static context has no base uri defined.

    

I am passing this on from one of my users, who pointed out that Saxon's
behavior differs from the spec. I believe that Saxon is correct and the
spec is wrong.

The referenced statement in the spec is: "For xs:float and xs:double
operands, floating point division is performed as specified in [IEEE
754-1985] and INF or -INF is returned if the divisor is zero."

But I believe that according to IEEE 754, dividing zero by zero gives
NaN.

It would be better not to make normative statements that attempt to
precis IEEE 754: it would be much safer if such things were said in
notes, so that it is clear the IEEE definition is the normative one.

Michael Kay


-----Original Message-----
From: saxon-help-admin@lists.sourceforge.net
[mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of Erik
Bruchez
Sent: 19 February 2004 01:19
To: saxon-help@lists.sourceforge.net
Subject: [saxon] Division by zero question


Consider this example:

   <xsl:value-of select="xs:double(0) div 0"/>

This operates a floating-point division. With Saxon 7.8, this returns
NaN, but the spec does specify that INF and -INF are returned in the
case of a division by zero:

http://www.w3.org/TR/xpath-functions/#func-numeric-divide

Is this a bug in Saxon, a bug or imprecision in the spec, or is this
implicitly covered by [IEEE 754-1985]?

-Erik

    

Agreed to elaborate the wording. 

Function and Operators: request for functionality


It is often required to test if a data model instance
would validate correctly, without actually attempting the
validation operation (which, if unsuccessful, raises
an irrecoverable error).

The signature of the function is:

fn:validatesCorrectly($x as node*) as xs:boolean
/* the name doesn't matter of course */

The semantics can be defined in terms of the validate{} expression:
validatesCorrectly($x) returns true if and only if the expression 
validate{$x}
would perform correctly and not would raise a dynamic error.

(As for any other expression) a query processor is allowed to statically
evaluate the function to either true or false if there is guaranteed 
that
the dynamic phase would evaluate it to the same value.

Best regards.

    

Discussed at Cannes.  WGs declined to make the change.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 7.4.7 and 7.4.8

The definitions of the fn:upper-case and fn:lower-case functions refer 
normatively to Unicode Case Mappings.  In Unicode 4.0, Unicode Case 
Mappings is specified in the "Case Mapping" subsection of section 4.2 of 
[1].  That document seems to admit several variations of case mapping.

F&O needs to clearly specify which level of case mapping is required, or 
whether it is implementation-defined.  If a case mapping that is 
locale-dependent was intended, F&O also needs to clearly specify how the 
locale is determined.

[1] http://www.unicode.org/versions/Unicode4.0.0/ch04.pdf

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
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.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 9.7.1

According to the first paragraph, "first the duration is calculated as the 
value of an xdt:dayTimeDuration in seconds. Then, starting from $arg2, the 
maximum number of months in the duration are calculated.  If there is a 
remaining number of days, they are discarded."

This description is not sufficiently precise.  Is the maximum number of 
months computed using the number of actual complete calendar months 
beginning from $arg2, or is it the maximum number of months that could be 
accommodated in that computed number of seconds, regardless of the 
starting point?  Or does month here refer to the time interval between a 
dateTime value and the dateTime value that would result from adding the 
duration P1M to it, as described in Section E.1 of XML Schema:  Datatypes?

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

The WGs adopted the proposal from Andrew Eisenberg in http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Aug/0074.html and agreed to remove the functions:
fn:subtract-dateTimes-yielding-yearMonthDuration and fn:subtract-dates-yielding-yearMonthDuration which has the same problem.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 7.6.1.1

In the last bulleted list, the first bullet describes the concept of 
captured substrings and how they are identified numerically, with the 
entire string matched being identified by the number zero.  The second 
bullet in the list describes the syntax for back references, used to refer 
to previously captured substrings within the regular expression.

Neither this bullet nor the syntax for back references defined in [23] and 
[23a] appears to prohibit \0 from appearing as a back reference within the 
regular expression, but clearly that would make no sense.  This 
restriction needs to be stated explicitly, or production [23a] needs to be 
modified to prevent \0 from being a syntactically correct back reference.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
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 make the suggested change.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 7.5

According to the sixth paragraph of this section, "In the definitions 
below, we say that $arg1 contains $arg2 at positions m through n if the 
collation units corresponding to characters in positions m to n of $arg1 
are the same as the collation units corresponding to all the characters of 
$arg2."

This definition is not sufficiently precise in the presence of ignorable 
collation units. The rules should be based on 
http://www.unicode.org/unicode/reports/tr10/#Searching (e.g. minimal or 
maximal. For all positive i and j, there is no match at Q[s-i,e+j].)

For example, '-' is ignorable for some collations. It is not clear whether 
substring-before("a-b", "b") returns "a" or "a-".  This needs to be 
clearly specified.  If it is implementation-dependent or 
implementation-defined, that should be clearly specified.


Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
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 add wording to explain the situation.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 7.3

The seventh paragraph of this section states that "the static context is 
not required to have a default collation specified."  It is not at all 
clear in the definition of the static context that the default collation 
could be unspecified. If that is the case, the definition of the static 
context should be clarified; if not, this text should be corrected.

If the default collation can be unspecified in the static context, this 
"system defined default" collation should be part of the dynamic context.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

The wording has been changed and does not refer to "system
define default collation".

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 1.5

The first paragraphs of 1.5.2 and 1.5.3 describe xdt:untypedAny and 
xdt:untypedAtomic as abstract types.  Section 2.4.1 of XPath describes 
these as concrete types.  The description in XPath is correct.  The 
sentences in these sections need to be corrected.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com 

STATUS:  These definitions were moved to the Datamodel document.  The two types mentioned are now defined as concrete types.

    

SECTION 15.1.9: fn:distinct-values

The rewritten XQuery use case 1.1.9.4 Q4 is very complicated. It traverses the children of <author> node and applies distinct-values to each of them. 
If this extra complexity is an unavoidable result of the change to
the signature of fn:distinct-values, then we should consider
reverting to:
fn:distinct-values($arg as item()*) as item()*

Q4 (original)
=============
<results>
  {
    for $a in distinct-values(document("bib.xml")//author)
    return
        <result>
            { $a }
            {
                for $b in document("bib.xml")/bib/book
                where some $ba in $b/author satisfies deep-equal($ba,$a)
                return $b/title
            }
        </result>
  }
</results>

Q4 (current)
============
<results>
  {
    let $a := doc("http://bstore1.example.com/bib/bib.xml")//author
    for $last in distinct-values($a/last),
        $first in distinct-values($a[last=$last]/first)
    order by $last, $first
    return
        <result>
            <author>
               <last>{ $last }</last>
               <first>{ $first }</first>
            </author>
            {
                for $b in doc("http://bstore1.example.com/bib.xml")/bib/book
                where some $ba in $b/author 
                      satisfies ($ba/last = $last and $ba/first=$first)
                return $b/title
            }
        </result>
  }
</results> 


- Steve B.

STATUS:  This was discussed at the Cannes meeting and there was
insufficient support to change the signature.

    

SECTION 7.5: Functions based on substring matching

Regarding collations that do not support collation units, the 
last sentence before the table in this section says "Such a 
collation may fail, or give unexpected results and the system 
may reject it."

Since the property of supporting collation units 
critically matters to the operation of certain functions, the user
has an interest in knowing whether a collation has this property.
This should be specifically stated to be an implementation-defined
property of the collation.

- Steve B.

Decided to add the suggested wording at the San Jose
meeting, 4/13/2004.

SECTION 7.3.1: Collations

This section is at pains to say how to specify (reference)
a collation, but it does not normatively say what a collation is.
Contrast this with the XQuery Language working draft, 2.1.1
"Static context", item regarding in-scope collations, where it
says "A collation may be regarded as an object that supports
two functions..." and a description of those two functions.
This tells me what a collation is.  I think this definition 
logically belongs in F&O.  The 
passage in the XQuery Language is merely telling how collations 
are part of the static context, and should not be the normative
text for what a collation is.

So what is the definition of collation?  We have seen one definition
in XQuery language.  F&O Section 7.5 "Functions based on substring 
matching" has a different definition.  
It seems that a collation consists of:

1. "the capability of deciding whether two strings are considered
equal, and if not, which of the strings should be regarded as 
preceding the other".  This capability completely captures the 
two points mentioned in XQuery Language.

2. Optionally, "decompose the string into a sequence of units, each 
unit consisting of one or more characters, such that two strings 
can be compared by pairwise comparison of these units".  
This capability might be realized by a function taking a single
argument of type xs:string and returning a sequence of type 
xs:string*, though I suspect that in practice implementations 
will find a way to represent the sequence with less overhead than
actually using a sequence of the data model.

3. Some means of indicating whether the collation has item #2.

This needs to be clarified.

- Steve B.

    

The WGs agreed to add a definition for collation.

SECTION 15.4.2: fn:id

It would be nice to have overloaded versions for fn:id and fn:idref, which explicitly specify the document node to be searched from.

fn:id($arg1 as xs:string*, $arg2 as node()?) as element()* 
fn:idref($arg1 as xs:string*, $arg2 as node()?) as node()* 


- Steve B.

STATUS:  This was approved at the Cannes meeting.

    

SECTION 15.1.10: fn:insert-before

The numeric types of parameters in fn:substring, fn:subsequence, fn:insert-before and fn:remove should be consistent, either all of xs:double, or all of xs:integer.

- Steve B.

    

The WGs decided not to make the suggested change at the Cambridge meeting..

SECTION 14.1.5: fn:lang

Just like the rest of the functions in section 14.1, it would be 
nice to have an overloaded version of fn:lang, which explicitly 
specifies the node to be operated on,

fn:lang($testlang as xs:string?, $arg as node()?)  as xs:boolean 


- Steve B.

    

The WGs agreed to add this signature.

SECTION Annex D: Error Summary

The F&O document (as well as other documents) summarize error codes in an Annex that is labelled to be non-normative.  In some ways, this makes sense, because XQuery does not specify any sort of an API by which errors can be "returned" to any entity.  However, it is clear that there will be more than one such API (e.g., JSR 225, XQJ, is defining such an API for use by Java programmers). 

It would be a serious problem if each API, and each XQuery implementation, were free to return radically different error codes for identical errors, as programmers would be unable to write code that is portable among XQuery engines. 

Some way to make the error codes themselves normative (but, of course, *not* the natural-language phrase that is associated with the codes).

One approach might be to state that whenever the XQuery specification indicates that a specific error is to be raised, that the specified (normative) error code must be made available in an implementation-defined way to the agent that caused the XQuery to be evaluted by the XQuery engine.  This is crude and clumsy, but definitely better than nothing!  The alternative would be to create an SQL-like diagnostics facility that would allow users to execute a subsequent query to retrieve the error code, etc.  I doubt that would be acceptable for XQuery 1.0, but would be deferred to a future version. 

- Steve B.

    

This was agreed to as part of Andrew Eisenberg's errors proposal
on May 4, 2005.

SECTION D: Error summary (nonnormative)

The title says this section is nonnormative.  However, in the 
normative part of the text, errors are not listed with both the 
QName and the mnemonic text.  See for example 5.1
"Constructor functions for XML Schema built-in types", which
has an error [invalid value for constructor]. If this section is 
not normative, where is the normative list of correspondences 
between QNames and mnemonic texts for errors?  Note that in the
XQuery language specification, this appendix is not labelled
non-normative.

- Steve B.

    

This was agreed to as part of Andrew Eisenberg's errors proposal
on May 4, 2005.

SECTION 17.1: casting from primitive types to primitive types

I have heard it said that xdt:dayTimeDuration and 
xdt:yearMonthDuration are to be treated as if they
were primitive types.  The fact that they are listed in 
this section seems to put them on a par with the primitive
types, but you don't actually say so.

If this is the intention, it would be better to adopt some
other term than "primitive".  Lincoln once asked, how many
legs does a dog have, if you call a tail a leg?  Answer:
four; calling a tail a leg doesn't make it a leg.  Just
the same, calling a derived type a primitive type just
shows that there is sone confusion about the distinction between
the two categories.  My thesaurus gives the following 
synonyms for primitive that you might consider:
basic, elementary, primary.  


- Steve B.

    

The WGs agreed to add wording to explain the situation.

F&O [6.2] xs:decimal overflow should not happen on rounding

As currently written the expression "1 div 3 * 100" causes a mandatory overflow
error. 

Per F&O 6.2:
   "For xs:decimal operations, overflow behavior ·must· raise an error [numeric
   operation overflow/underflow]. On underflow, 0.0 must be returned." 

Per F&O 6.2.4:
   "As a special case, if the types of both $arg1 and $arg2 are xs:integer,
   then the return type is xs:decimal." 

So 1 and 3 are typed as xs:integer and their division results in an xs:decimal
which cannot be precisely represented, causing an overflow error.  This should
not happen.   

(Note that depending on your reading of the spec, the simple division may not be
an "xs:decimal" operation, but the "* 100" clearly makes it an xs:decimal
operation which will cause an overflow error.)

Solution: Overflow/underflow should happen only for numbers exceeding the
implementation's xs:decimal range, not for precision-related roundings. 

This is especially onerous given that such errors cannot be caught and handled
by the XQuery application; see CER-05.
    

Please propose new wording.

F&O 7.6

Add a function that gives the matches of a regular expression.

    fn:extract-match( $source as xs:string, $regex as xs:string ) as xs:string*

For example:

    extract-match( "some text with 12-11-02 in it", "(\d{2})-(\d{2})-(\d{2})" )
        => ("12", "11", "02" )

This ability is necessary for implementing replace() anyway, but you cannot
do this inside XQuery otherwise, and it is key for performing data
normalization or hit highlighting against regular expression matches.

    

The WGs decided not to make the suggested change at the Cambridge meeting.

F&O 5.1.1, 5.1.2, 5.1.3

The functions fn:zero-or-one, fn:one-or-more, and fn:exactly-one can trivially
be written as user functions and provide little benefit. Given widely useful
functions such as value-union that are not being provided, there seems little
justification to require these functions. Suggest they be removed.

    

This has been discussed and there is significant support for
keeping these functions.

F&O 7.4.3

Making the positional parameters to fn:substring be xs:double instead of
xs:integer adds complexity and confusion for no obvious benefit. If the
rationale is to take advantage of the automatic promotion rules, it is
difficult to come up with realistic use cases involving mathematic expressions
on substring positions that would lead to values requiring such promotion.
Request that if there is no sound justification, change the signatures to use
xs:integer instead.

    

The WGs decided not to make the suggested change at the Cambridge meeting..

F&O 7.4.3

fn:substring takes positional parameters to figure out which substring to
select, but no functions are provided to determine the position of any
interesting piece of a string. Request the addition of such functions.

Options:
(a) One function that returns positions of all matches, similar to fn:index-of
    for sequence:

    fn:position-of( $source as xs:string, $pattern as xs:string ) as xs:integer*

    Example:
       let $suffix := substring( $url, position-of( $url, "/")[last()] )
       return substring( $suffix, position-of( $suffix, "#" )[1] )

(b) One function that gives first matching position, and one that gives
    the last matching position, similar to similar functions in various
    programming languages:

    fn:position-of( $source as xs:string, $pattern as xs:string ) as xs:integer
    fn:last-position-of( $source as xs:string, $pattern as xs:string ) as xs:integer

    Example: 
       let $suffix := substring( $url, last-position-of( $url, "/" ) )
       return substring( $suffix, position-of( $suffix, "#" ) )

    

The WGs decided not to make the suggested change at the Cambridge meeting..

SECTION 17.8.1: casting to xs:float

The second bullet says "If ST is xs:double and SV can be 
represented in the value space of xs:float...".  This is open
to the interpretation "...can be represented in the value space
of xs:float without truncation or rounding...".  However, 
the third bullet (when SV cannot be represented in the value 
space of xs:float) does not include a case for truncation or
rounding, so it seems that the second bullet must mean that
truncation or rounding is acceptable.  This should be clarified
by rewriting the second bullet.


- Steve B.

    

The WGs decided to accept the proposal by Michael Kay in http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Aug/0089.html to address this issue.

SECTION 17.5: Casting across the type hierarchy

Step 1 says to cast up the hierarchy to the primitive type of the
source.  It is not clear whether the types xdt:yearMonthDuration
and xdt:dayTimeDuration are regarded as primitive types for the
purpose of this step.  If the source value's type is one of 
these types, or a restriction of them, do you cast back to
xs:duration or just to xdt:yearMonthDuration or xdt:dayTimeDuration?
The same remark probably applies to xs:integer, since I have heard 
it said that xs:integer is to be treated as if it were a primitive
type for purposes of casting.

- Steve B.

    

The WGs agreed to add wording to explain the situation.

SECTION 16.4: fn:current-date

It is not stated whether there is any relationship between 
the value of fn:current-date and fn:current-dateTime, merely that
both are stable and both represent some instant during the 
current query or transformation.  This seemingly means that if
a query or transformation runs across a change of day, then 
fn:current-date might not be the same as 
xs:date (fn:current-dateTime).  This seems undesirable.  It 
would be preferable to simply define fn:current-date() as
xs:date (fn:current-dateTime()).  Similarly, fn:current-time()
should be defined as xs:time (fn:current-dateTime())

- Steve B.

    

The WGs agreed to make the suggested change.

SECTION 15.4.5: fn:collection

It says that this function is stable, meaning that two invocations
during the same expression evaluation have the same result.
Since the size of the result of an fn:collection evaluation may
be very large, it will not be practical for XQuery to take a
snapshot and guarantee stability that way, and consequently 
fn:collection must rely on resolving the URI on demand.
This means that the stability requirement is unreasonable in many 
environments:

a) if fn:collection is evaluated by resolving to a resource that
is outside the transaction management of XQuery, then the 
values at that resource might change dynamically, and not just
at times between evaluations of XQuery expressions. 

b) if fn:collection is evaluated by resolving to a resource such
as a relational database, which does not assure a stable ordering
of results.

Perhaps the solution is to provide fn:stable-collection
and fn:unstable-collection.  fn:stable-collection would 
return an error if it is not possible to assure stability.
Let the user indicate whether he really needs stability.

- Steve B.

    

The WGs decided not to change the stability requirement for fn:collection.

SECTION 15.4.4: fn:doc

It says that this function is stable, meaning that two invocations
during the same expression evaluation have the same result.
Since the size of the result of an fn:doc evaluation may
be very large, it will not be practical for XQuery to take a
snapshot and guarantee stability that way, and consequently 
fn:doc must rely on resolving the URI on demand.
This means that the stability requirement is unreasonable in many 
environments:

a) if fn:doc is evaluated by resolving to a resource that
is outside the transaction management of XQuery, then the 
values at that resource might change dynamically, and not just
at times between evaluations of XQuery expressions. 

b) if fn:doc is evaluated by resolving to a resource such
as a relational database, which may provide suitable transaction
semantics but does not assure a stable ordering of results.

Perhaps the solution is to provide fn:stable-doc and 
fn:unstable-doc.  fn:stable-doc would return an error if
it is not possible to assure stability of the result.

- Steve B.

    

The WGs said that this was a conscious decision and changing it
would do more harm than good.  Implementations could provide functions
with alternate semantics if they so desired.
Joint WGs telcon, May 25, 2004.

SECTION 9.7.1: fn:subtract-dateTimes-yielding-yearMonthDuration

The name of this function is too long.  Perhaps 
fn:yearMonth-subtraction ?  Similarly for 
fn:subtract-dateTimes-yielding-dayTimeDuration.


- Steve B.

    

The WGs decided not to make the suggested change at the Cambridge meeting..

SECTION 9.4: component extraction functions on duration, date and time

The names of these functions are rather long, and could be 
shortened by using overloading on argument types to just
fn:get-year, etc. 


- Steve B.

    

The WGs decided not to make the suggested change at the Cambridge meeting..

SECTION 6.4.1: fn:abs

This function may raise an overflow error if the absolute value
exceeds the capacity of the return type.


- Steve B.

    

I thought positive and negative numbers had equal magnitudes.

Jim Melton is right.  We need an error condition to cover this case.

SECTION 6.2.8: op:numeric-unary-minus

You should also say that this function might raise an overflow
exception if the negative value exceeds the capacity of the 
type, which typically happens for the largest negative value of
xs:integer.



- Steve B.

    

I thought positive and negative numbers had equal magnitudes.

Jim Melton is right.  We need an error condition to cover this case.

SECTION 6.2: functions and operators on numerics

There is no statement about how to deal with truncation or 
rounding.  For xs:float or xs:double, you can say that you follow
the IEEE rules.  For integers, this is only an issue for 
op:numeric-divide (you have a statement that there is no rounding 
in op:numeric-integer-divide).  The main issue is xs:decimal.
At the very least, this should be implementation-defined.

- Steve B.

    

The WGs agreed to add clarifying wording.

This comment concerns section 7.6.1 of XQuery 1.0 and XPath 2.0 Functions and Operators.

Since the regular expression syntax adds the meta-character $, there should be a corresponding escape \$ added to the single-character escapes (schema production [24]).

(There is already an escape for ^ because schema uses it as a metacharacter in character groups.)

You should also urge the Schema WG to add this escape, for consistency.  It would not break any existing schema regular expressions.

-- Richard

The WGs agreed to make the suggested change.

I think it's editorial error:

If input sequence is not empty, doesn't contains NaN's and error is not raised,
the result of the function is defined as result of the expression:

$c[1] + fn:sum(subsequence($c, 2))

So in last recursion, when count($c)=1, fn:sum is called again with empty sequence as parameter
and returns 0.0e0 of type double. When sequence contains values of types other than numeric (dayTimeDuration etc),
addition will raise type error. According to this fn:sum will not work for sequence of any types other than numeric...

Also this expression should be defined for two-argument version of fn:sum and say that second argument is assumend 0.0e0
if not specified. It should be:

if (count($c)=1)
    $c[1]
else
    $c[1] + fn:sum(subsequence($c, 2),$zero)

Similar definitions in fn:min and fn:max are not clear:
"If the items in the value of $arg are of type xs:string or types derived by restriction from xs:string, then the determination of the greatest item is made according to the collation that is used."

"according to the collation" is not precise, expression with fn:compare should be used.
Plus there are two typos in expressions used for general case: ')' on end of first line and ']' on end of third
and variable $collation mentioned below expression is not used.

Best Regards,
Noe Michejda
7th Portal S.C.

    

Thank you for your valuable editorial suggestions.

Functions and operators: request for functionality

XQuery's function and operators builtin library should
have enough functions to introspect all the data model
accessors for the nodes. e.g. we should be able to ask for
the nillable property and for the type annotation.

    

The WGs decided on 8/23 that such functionality should be postponed to vNext.

Collections look like a nice concept, but they don't currently
exist on the Web. It's straightforward to take a document identified
by an URI and use the Web to access that document. For collections,
there is no protocol or mechanism. The way the specs currently read,
they will either stay vaporware or be badly implementation-dependent.


Regards,   Martin.

    

The WGs decided to add some wording motivating the function.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-008 Casting and constructor fidelity (5.1, 17.6)

We are confused regarding the definitions of casting and construction
and how they appeal to each other and to XML Schema.  Accordingly, we
have the following largely-editorial suggestions:

1) add more detail about the raising of errors during construction. The
only error indication we see is:

      If the value passed to a constructor is illegal for the
      datatype to be constructed, an error is raised [invalid
      value for constructor].

It's not clear to us if this also applies if the value is a string,
which is otherwise discussed in the paragraph following the cited
statement.

2) in 5.1 and elsewhere where schema validation is appealed to, it
should be clear that the result is a value in the value space
corresponding to  the input lexical form.

3) in 17.6 "validated as a lexical value of the target type" should be
brought better into line with 5.1 and Schema Datatypes ("lexical form"
preferred and consistent whitespace handling suggested).

4) 17.6 and 17.8 appear to both handle casting from string to float.
Does one take precedence or is one meant to be redundant?

    

Thank you for your editorial comments.  We have revised the
wording taking these into account.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-007 Casting numerics and inconsistency (17.8)

We note that 17.8.3 can raise one error for any failure to
convert to decimal, but 17.8.4 can use one of two errors
for failure to convert to integer.  We believe the failure
cases are the same (number too large or illegal value, e.g., NaN),
so we think these sections should be consistent.

    

The WGs decided to adopt the suggestion.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-006 Casting numerics and implementation limits (17.8)

We ask that when reference is made to implementation limits, that an
link be provided to either XML Schema's indication of a minimum of 18
decimal digits or to the corresponding statement withing the DM family
of specifications.  In particular, 17.8.3 explicitly mentions an
implementation's supported decimal values, and 17.8.4 implicitly
refers to an implementation's supported integer values.

    

The WGs decided to adopt the suggestion.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-005 Casting xs:double and xs:float to xs:string (17.7)

We note that F&O does not use the XML Schema canonical
representations of xs:decimal, xs:float, and xs:double.  We
know that XML Schema is under-specified in this area, and we are
working to improve our specification in either errata fixes or a
future version (see our RQ-1,
http://www.w3.org/XML/Group/2002/07/xmlschema-1.1-current-reqs-
list.html#canonical-float).

We suggest that we coordinate efforts to find a mutually
satisfactory resolution.

That aside, we suspect the written descriptions do not have their
intended effect.

       If SV has an absolute value that is greater than or equal to
       0.000001 (one millionth) and less than 1000000 (one million),
       then the value is converted to an xs:decimal and the resulting
       xs:decimal is converted to an xs:string  using the rules above.

The casting to decimal rules imply that casting xs:float("1.1") to
xs:decimal yields 1.10000002384185791015625 which is the exact value of
the float that represents "1.1" (and therefore it is the "numerically
closest" value).  Does this mean casting xs:float("1.1") to string
yields "1.10000002384185791015625"?

    

The WGs decided to adopt the suggestion.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-002 Datetime without a timezone

    From section 1.6 "xs:dateTime, xs:date and xs:time values"

        xs:dateTime, xs:date and xs:time values are represented in the
        Section 4.3.1 Mapping PSVI Additions to TypesDM as tuples: a
        xs:dateTime, xs:date or xs:time value without a timezone and a
        timezone represented as a xdt:dayTimeDuration value.

The above doesn't quite agree with the relevant section of DM or with
your examples, in which the first member of the tuple does have a
timezone which must be Z.

    

Thanks!  The wording has been aligned.

1) The algorithm contains:

if ($parameter1 instance of element(*, xs:anySimpleType) and
      ($parameter2 instance of element(*, xs:anySimpleType))
        return fn:deep-equal(fn:data($parameter1), fn:data($parameter2))

Why is no collation parameter passed to the recursive call of 
fn:deep-equal?

2) The formatting and indentation of the code is inconsistent.

Till Westmann

    

On May 4, 2004 we decided to accept wording suggested by Mike Kay.

The dynamic type of this function should depend on the types of its 
arguments.
So bold italics should be used for the result type and there should be 
a reference to the formal semantics.

Till Westmann

    

The WGs agreed to add clarifying wording.

The description contains:

This function, invoked with the second signature, backs up the "eq", 
"ne", "gt", "lt", "le" and "ge" operators on string values.

The second signature requires a collation, so either it should be the 
first signature or the collation should be specified.

Till Westmann

    

This is a typo.  Will fix.

The description contains:

If the argument is less than zero (0), but greater than or equal to 
-0.5, then negative zero (-0) is returned.

So ceiling(-0.5) = -0 and ceiling(-0.6) = +0?

Till Westmann

STATUS:  This is a bug.  Fixed.

    

The text says that "If the static context does not have a default 
collation specified, a system defined default can be invoked." but in 
the algorithm that follows this "system defined default" is not 
mentioned. This should be fixed.

Till Westmann

    

The wording has been changed and does not refer to "system
define default collation".

There is no description of the result for small negatives.

Is fn:round-half-to-even(xs:double(-0.3)) eq -0 (as is 
fn:round(xs:double(-0.3))) or is it +0?

Till Westmann

    

Added appropriate wording.

The function descriptions contain

If the type of $arg is a type derived from one of the numeric types, 
the type of the return is the parent numeric type.

1) The formal semantics say that the input type is promoted. The 
descriptions in the F&O and in the FS should be aligned.

2) Instead of "the return" it should be "the return value" or "the 
result".

Till Westmann

    

The WGs agreed to make editorial changes to address the comment.
Joint WG telcon May 26, 2004

The result types for these constructor functions:

xs:dateTime($arg  as xdt:anyAtomicType) as (xs:dateTime, 
xdt:dayTimeDuration)
xs:time($arg as xdt:anyAtomicType) as (xs:time, xdt:dayTimeDuration)
xs:date($arg as xdt:anyAtomicType) as (xs:date, xdt:dayTimeDuration)

are no SequenceTypes. This is inconsistent wrt function declarations in 
the query prolog.

Till Westmann

    

The WGs agreed to change the constructor functions to return
single values of the appropriate type.
Joint WG telcon May 26, 2004

The document says: "Each error defined in this document is identified 
by an xs:QName that is in the namespace asssociated with the xdt: 
prefix.". But in Appendix D the "err:" prefix is used instead of the 
"xdt:" prefix.

Till Westmann

STATUS:  Fixed.

    

The summary for the second form of the base-uri mentions "the preceding 
rules".
What rules are there/needed to get the base-uri property from the 
static context?

Till Westmann

    

This is a typo.  Will fix.

As currently specified, fn:contains() raises a type error for elements 
of complex type with complex content.  Suppose I have the following element:

<people xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="file:///c:/temp/foo.xsd">
    <person>Michael Kay</person>
    <person>Jonathan Robie</person>
    <person>Michael Rys</person>
</people>

Which is governed by the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified">
  <xs:element name="people">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="person"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="person" type="xs:string"/>
</xs:schema>

Now I want to do the following query:

    let $people := doc('people.xml')
    return contains($people, "Rys")

When the query attempts to cast $people to a string, it will try to 
atomize the element using dm:typed-value(), and the following rule applies:

     If the node has a complex type with complex content, raises a
     type error, which may be handled by the host language.

We should see if there are other functions/operators that have this same 
problem.

Jonathan

    

WGs agreed that no change was needed.

We currently have a function called fn:string() and a
constructor called xs:string(), which both create strings. There  
is some justification for having both. xs:string is a constructor  
for a built-in type, and all built-in types have associated
constructors. fn:string() is a widely used function in XPath 1.0,
so it is difficult to remove it at this point.

But they are defined differently. fn:string() uses the
string value, whereas xs:string() atomizes the node and casts the
result to a string. These two definitions give subtly different
results. Could one be made a synonym for the other, to avoid
confusion?

Jonathan

    

WGs agreed that no change was needed.

The type of each of these three functions is underspecified. In all 
three cases, we are told, "The type of the result depends on the type of 
$arg." None of these functions tells us how to determine the type of the 
result from the type of $arg.

Jonathan

    

We decided add references to a section in FS that explains the
types in detail.

The fn:replace() function now allows $0 in the replacement string but
the error message still says:

An error is raised [invalid replacement string] if the value of
$replacement contains a "$" character that is not immediately followed
by a digit 1-9 and not immediately preceded by a "\".

Change 1-9 to read 0-9.

Michael Kay

STATUS:  Fixed.

    

F+O still describes casts and constructor functions in separate
sections: it is not clear that they are completely synonymous with each
other.

For example, it appears that you will get different errors depending on
whether you use a cast or a constructor function. 

Constructors should be defined entirely in terms of casts, or vice
versa. If the two cases generate different error codes, implementations
can't treat them as being purely different surface syntax for the same
operation.

Note also my separate comment that the XPath language spec defines error
codes for casting which conflict with the codes defined in F+O.

Michael Kay

    

WGs agreed that wording should be improved and a single error returned.

This function raises an error if the second argument is an empty
sequence. So why does the signature allow an empty sequence?

Also, the error raised (invalid lexical value) is inappropriate.

Michael Kay

    

WGs agreed to make this change.

Hi,

  XML 1.0 TE:

[...]
  Note:

  Language information may also be provided by external transport
  protocols (e.g. HTTP or MIME). When available, this information may be
  used by XML applications, but the more local information provided by
  xml:lang should be considered to override it. 
[...]

The definiton of lang() does not consider such protocol information.
Please include explicit information whether implementations must use
such information or must not use such information.

    

We decided no change was required.

Disagrees with the WG decision.
Joint WGs telcon, May 25, 2004.

The WGs took the position that protocol information was not
stored in the datamodel and was not used by fn:lang().

In section 9.1.1 (Limits and precision), F&O says:

"A processor that limits the number of digits in date and time datatype
representations may encounter overflow and underflow conditions when it
tries to execute the functions in 9.7 Adding and Subtracting Durations From
dateTime, date and time. In these situations, the processor .must. return
zero in case of underflow and .must. raise an error [overflow in date/time
arithmetic] in case of overflow."
 
The last sentence seems to imply that the return value for the functions
should be a numeric value 0 in the case of underflow. But this seems
strange, since none of the functions/operators described in that section
return numeric values in any other case.  I would think you would want just
the part of the time or duration that is causing underflow (e.g. the number
of seconds) to be treated as zero.  
 
Thanks,
Priscilla Walmsley

    

Agreed to clarify wording.

The description of the resolve-QName function says that the error "invalid
lexical value" is raised if $element is the empty sequence.  This seems to
be the wrong error message.  Perhaps "no namespace found for prefix" would
be more appropriate?

I'm also not sure I understand why the function signature even allows
$element to be the empty sequence, if the processor automatically raises an
error when it is the empty sequence.
 
Thanks,
Priscilla Walmsley

    

WGs agreed to make this change.

When describing adjust-date-to-timezone, F&O says:

"If $timezone is not the empty sequence, then the result is $arg with
$timezone as its timezone component."

I think this means that a timezone adjustment is performed, based on the
time value 00:00:00, similar to the other "adjust" functions.  But the
current text seems vague, and I know of one implementation that does not
work this way.  

I would recommend the following more specific text (modeled after the text
for adjust-time-to-timezone):
-----------------------------
If $arg has a timezone component and $timezone is not the empty sequence,
then:

- Let $srcdt be an xs:dateTime value, with 00:00:00 for the time component
and date and timezone components that are the same as the date and timezone
components of $arg.

- Let $r be the result of evaluating

    fn:adjust-dateTime-to-timezone($srcdt, $timezone)

- The result of this function will be a date value that has date and
timezone components that are the same as the date and timezone components of
$r.
-------------------------------


Thanks,
Priscilla Walmsley

    

Thanks!  That's better wording.

This Last Call comment proposes a new XPath/XQuery function, possibly 
named fn:atom(). The result of fn:atom() is the same as that of fn:data(), 
except in those cases where fn:data() would construct a typed value by 
concatenating the string values of descendant elements. In these cases, 
fn:atom() returns an empty sequence. The definition of fn:atom() is as 
follows:

fn:atom($arg as item()*) as xdt:anyAtomicType*

The result of fn:atom is the sequence of atomic values produced by 
applying the following rules to each item in $arg:

1. If the item is an atomic value, it is returned.

2. If the item is a document node, the result is ().

3. If the item is an attribute, text, comment, processing instruction, or 
namespace node, the typed value of the node is returned (same as fn:data). 


4. If the item is an element node (regardless of type annotation) that has 
no child element node, the typed value of the node is returned.

5. If the item is an element node (regardless of type annotation) that has 
a child element node, an empty sequence is returned.

The advantages of the proposed function are as follows:

(a) Suppose that $node1 and $node2 are element nodes with a type 
annotation that permits mixed content. Suppose that $node1 is bound to 
<node><a>1</a><b>2</b></node>, and $node2 is bound to 
<node><b>1</b><a>2</a></node>.  Then data($node1) = data($node2) is true, 
because the typed value returned by the data function ignores nested 
markup. This is a undesirable result in certain applications. The atom() 
function would enable a user to avoid this anomaly by writing atom($node1) 
= atom($node2). In this case both atom() functions would return () and the 
result of the predicate would be false.

(b) Suppose $sal is bound to the following untyped node: 
<salary><base>17</base><bonus>25</bonus></salary>.  Consider the predicate 
$sal > 300. In processing this query, the data function will be implicitly 
invoked and will return the untyped atomic value "1725". Comparing this 
value with 300 will implicitly cast it to the integer 1725. The value of 
the predicate is true. This anomaly could be avoided by using the atom 
function, as follows: atom($sal) > 300. This revised predicate is false.

(c) The fn:atom function can be used to search for elements that have a 
given atomic value without incurring the cost of concatenating potentially 
huge volumes of data. For example, consider the query:
/book[title = "War and Peace"]//*[atom(.) = "Leo Tolstoy"]
This query can quickly find leaf nodes with the atomic content "Leo 
Tolstoy" without computing the string-values of all the intermediate nodes 
in the tree, some of which are very large (the topmost element contains 
the whole book!)

We believe that this function is sufficiently important to justify 
including it in the standard function library in order to make 
applications portable.

Cheers,
--Don Chamberlin

    

WGs decided not to add this function.

F&O section 7.5.4 (definition of function fn:substring-before) states:

"If the value of $arg2 is the zero-length string, then the function returns
the zero-length string."

But later example is given:
"fn:substring-before("Baloney!","") returns "Baloney!". "

Then 7.5.5 fn:substring-after states:

"If the value of $arg2 is the zero-length string, then the function returns
the value of $arg1."

I think error in definition of fn:substring-before, behavior should be the
same as in fn:substring-after.
"If the value of $arg2 is the zero-length string, then the function returns
the value of $arg1."

If definition is correct and example mistaken, I think it is bad idea to
return zero-length string in such case.

Best regards,
Noe Michejda
7th Portal S.C.

STATUS:  Agreed to fix example in Tampa.

    

Agreed to fix the example.

SUGGESTION 1:

7.4.7 fn:upper-case and 7.4.8 fn:lower-case
How we can find what language to use? From default collation? It is not
going to be flexible if from default collation.
Possible solution- second optional parameter xml:lang

SUGGESTION 2:

7.5 Functions Based on Substring Matching
The rules are ambiguous if there are ignorable collation units.

example
'-' is ignorable for some collations. substring-before("a-b", "b") returns
"a"
or "a-"?

Matching rules should be more precise and based on
http://www.unicode.org/unicode/reports/tr10/#Searching
(e.g. minimal or maximal.
For all positive i and j, there is
no match at Q[s-i,e+j].)


Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839

I don't think we want to be too prescriptive in terms of the collation
algorithms that vendors use. But I agree with you that the rules for
substring-before and substring-after could be clearer.

I would suggest that substring-before($s1, $s2) is defined as:

substring($s1, 1, $n -1) where $n is the lowest integer that satisfies
starts-with(substring($s1, $n), $s2)

And substring-after($s1, $s2) is defined as:

substring($s1, $n + string-length($s2)) where $n in the lowest integer
that satisfies starts-with(substring($s1, $n), $s2)

(these rules will need augmenting for the case where there is no match).

I think the rules for starts-with, contains, and ends-with are
unambiguous.

>We made the decision to go for a language-independent mapping of
>lower-case upper-case and vice-versa.
Then one has to remove notes from
7.4.7 fn:upper-case and 7.4.8 fn:lower-case where you are saying
explicitly that fn:upper-case and 7.4.8 fn:lower-case are language
dependent.
You would need fn:upper-case fn:lower-case functionality
for other staff (e.g. xsl:number) anyway.

I don't also understand why we cannot permit
people  to have richer (i18n friendly) functionality. (It could be just
permission
set of languages could be implementation defend and a "default" could
a language independent one)

> I don't think we want to be too prescriptive in terms of the
>collation algorithms that vendors use.

I would agree if it would be difficult to implement .
Otherwise unambiguous implementable specs is a good idea.


> would suggest that substring-before($s1, $s2) is defined as:
...
I don't understand the rational of using XSLT specific definitions
for string matching if it has already has been defined by common
Unicode specs.

>I think the rules for starts-with, contains, and ends-with are
>unambiguous
I think they are ambiguous  starts-with("-a", " a") true a false?

I think the rationale is:

Firstly, we aren't insisting that all collations use the Unicode
collation algorithm.

Secondly, the Unicode TR is not rigorous enough. The "Searching" section
is labeled as "informative", and it's written in the style of a
discussion of options and possibilities, not a specification that
products can conform to.

However, we have been guided in writing these specifications by the
Unicode work (which has gone on in parallel - it wasn't all there when
we started) and this should continue. We could also probably align the
terminology better - I think our collation units are probably the same
thing as Unicode's collation elements (though perhaps we avoided
"elements" as being a reserved word).


> 
> >I think the rules for starts-with, contains, and ends-with are 
> >unambiguous
> I think they are ambiguous  starts-with("-a", " a") true a false?
> 

Sorry, I meant that the rules were unambiguous given the existence of a
function that maps a sequence of characters to a sequence of collation
units (which is what the collation provides).

fn:lang returns 'false' if there is no context node.  Other
compatibility functions, such as fn:id, raise an error if there is no
context node.
Is there a reason for this discrepancy?

STATUS: On the Feb 3 F&O telcon we agreed to raise errors:

  context item undefined - FONC0001
  context item not a node - FONC0002

Proposal:
    

Errors should be raised.

Nothing seems to be specified about the number of digits that
should be generated when casting from double or float to string.

whether the absolute value is within or without the range of 1e-6 to 1e6
the problem is the same: "the" canonical lexical representation,
  as defined in [XML Schema Part 2: Datatypes] doesn't precise it.

-- 
Xavier FRANC

SUGGESTED WORDING
NaN has the canonical form "NaN".  Infinity and negative infinity have
the canonical forms INF and -INF respectively.  Besides these special
values,  the general 
form of the canonical form for float/double is a mantissa, which is a
decimal, followed by E
 followed by an exponent which is an integer. Leading zeroes and the
preceding optional "+" 
sign are prohibited in the exponent. If the exponent is zero it must
be indicated by E0 For 
the mantissa, the preceding optional "+" sign is prohibited and the
decimal point is 
required. Leading and trailing zeroes are prohibited subject to the
following: number 
representations must be normalized such that there is a single digit
which is non-zero to 
the left of the decimal point and at least a single digit to the right
of the decimal point 
unless the value being represented is zero.  The canonical form of
positive zero is 0.0E0. 
If implementations need to distinguish negative zero from positive
zero, the canonical form 
for negative zero is -0.0E0.  Beyond the one required digit after the
decimal point in the 
mantissa, there must be as many, but only as many, additional digits
as are needed to 
uniquely distinguish the value from all other values for the datatype.

WGs approved precise wording for casting float/double to string.

The normal rules for casting to a derived type are that the value must
satisfy all the facets of the target type. But there are special rules in
section 17.8.4 for xs:integer, which cause the supplied value to be
truncated towards zero.

It's not clear whether or not these special rules also apply if the target
type is a subtype of xs:integer. For example, xs:short(4.3). 

I think they should apply. But the rules then need to be modified to allow
this. For example, the clause "and TV is xs:integer(IV)" is wrong.

Michael Kay

PS: these rules still have references to xs:anySimpleType. This doesn't
belong in the casting rules because it's not an atomic type. It's gone from
the table, but not from the text.

STATUS: We discussed on 1/6 F&O telcon.  Agreed to adopt wording on 1/19. Close.

    

http://www.w3.org/TR/xquery-operators/#func-sum
http://www.w3.org/TR/xquery-operators/#xpath1-compatibility

This comment could be regarded as a follow-up to my post
2003Jun/0113.html

Now the situation is the other way around:
sum() returns NaN if the value NaN occurs within the sequence (like in XPath1)
but appendix B states that NaNs are discarded (this is the definition in the 
previous version).

Regards,
Oliver Becker

It appears that the compatibility appendix
was not updated when the definition of the function was changed.  We
will fix that.

I commented on the previous draft (a day or so before the release of the
current draft) that deep-equal would be better in the user-defined appendix:

2003Nov/0210.html

The version in this draft appears to be unchanged, so the comments made
there still apply. (deep-equal appears to be completely broken wrt to
document nodes).

In addition I have noticed some further problems with the given
definition.

1) The is-namespace-node() function should be in some non null
   (example.org) namespace so that this definition is legal in xslt as a
   user-defined function.


2) the note 

     The contents of comments and processing instructions are
     significant only if these nodes are used directly as arguments to
     the function, not if they appear as children of the nodes supplied
     as arguments.

is strictly true (the content is insignificant) but it is rather  misleading.
The _content_ of comments are (bizarrely) not compared by the given
definition unless they are items in the sequence being compared, but
comments are not ignored: their _presence_ affects the equality.

given

1 <x>ab</x>
2 <x><!-- z -->ab</x>
3 <x>a<!-- z -->b</x>
4 <x>ab<!-- z --></x>
5 <x>a<!-- zz -->b</x>

1 == 2 == 4
3 == 5

as in 1,2,4 x has a single text node child with value ab but in 3 and 5
there are two text node children.

This is a particularly arbitrary choice of equality definition.

David

    

On May 4, 2004 we decided to accept Mike Kay's proposal for this function.

Acknowledged.

fn:root() is defined as follows:

"14.1.9 fn:root
fn:root() as node() 
fn:root($arg as node()?) as node()? "

The examples in 14.1.9.1 end with the following sentence:

"Note:

We could make the final three examples type-safe by wrapping their
operands with fn:exactly-one()."


This is the correct way to define a function without sacrificing its type
definition by allowing node()* as done elsewhere (see my comments in this
list on this anomaly in the definition of min(), max() and avg()).


I want to congratulate the authors for the correct definition and examples
of fn:root().

I strongly recommend that all other function definitions, in which the
type definitions are severely underspecified by allowing node()* or 
item()* (and which alters the normally accepted behaviour of these
functions and makes them less meaningful and actually defeats the purpose
of type-checking) be defined properly as this is done with the function
fn:root().


Once again -- congratulations for the correct function definition.

Thank you.

Dimitre Novatchev.

We are glad that you like the definition of fn:root().  However, we
could not find other functions that allow
node()* or item()* that you suggested should be changed.  If you can
make specific suggestions, the WGs would
be happy to consider them.

Allowing the functions fn:max, fn:min and fn:avg to accept an empty
sequence as argument is wrong and will make using these functions
difficult and confusing.

Trying to calculate the minimum, maximum or average of an empty sequence
is an error and must be reported at the place where this error occurs.

Returning the empty sequence instead is delaying the moment at which it is
realized that there is an error. This will lead to hidden, long-time
undiscovered errors and to difficulty in tracking the exact cause of an
error, as there has not been an immediate raising of an error as reaction
to the exact cause.

Why should the programmer be forced to manually include additional code to
check the type of the returned value and manually raise an error, if this
can be done automatically by the type-checking system?


Note: These comments apply to all cases in the WD, which allow an empty
sequence argument, for which the function has no meaning. In all such
cases the type of the function must be changed to accept a non-empty
sequence.

It is necessary to analyze all cases where a fn:function is returning the
empty sequence and to decide case by case whether having such a result is
meaningful.

It is a benefit of typing that such errors can be caught (even sometimes
statically) and immediately reported in all cases.


Dimitre Novatchev
    

We discussed this during the joint XML
Query/XSL WG meetings on 1/8/2004.  The WGs declined to make the change
you suggested

Here is a summary of the discussion.
Three points were made.

1.  If we are using, say, fn:avg to calculate the average salary of
employees in each department then if there is a department with no
employees the it's better to return the empty sequence for this
department rather than raise an error.

2.  You can wrap the function call in fn:exactly-one to make sure that
fn:avg, for example, returns a single result.

3.  Empty sequences are pervasive in the datamodel.  It does not seem to
be a good idea to raise errors when functions are passed the empty
sequence.

Please let us know if you are satisfied with this decision.

Two issues and a comment:

Issue 1:
=======
The following text contradicts the code that it attempts to explain:

"Return true if the the two nodes have names that compare equal as
xs:QNames or if they do not have names.

if (not(fn:deep-equal(fn:node-name($parameter1),
fn:node-name($parameter2)))) 
then fn:false()
else"

Obviuosly, the explanation must be something like:

     "Return false if the two nodes have different names."

Issue 2:
=======
"Check if both element nodes have simple types. if so, compare their typed
values, else compare their children recursively. The result is true if and
only if the children of both nodes are all pairwise deep-equal, ignoring
comment and processing instruction node children in both cases."

What is the rationale for ignoring comment and PI children?

Such a decision results in the strange fact that two nodes with different
number of children may be deep-equal.

Comment:
=======
Using code to define the function is a good step forward, however the
presented code seems too lengthy and unstructured.

Probably the code would be shorter and more understandable if a few
auxiliarry functions were defined and used in it.


Dimitre Novatchev.

    

On May 4, 2004 we decided to accept wording suggested by Mike Kay.

There are two issues with this function:

 1.  The function name does not accurately reflect its semantic � it does
     not provide an answer if a sequence exists, but if a sequence 
     is non-empty.

Because 
   
     not(empty($seq)) = exists($seq)

     a better name for this function would be notEmpty() or nonEmpty()

 2. The example in 15.1.8.1 is incorrect:

    "fn:exists($seq) returns true."

The above statement is true only if $seq is non-empty and $seq has not
been defined. One can incorrectly deduce that the function returns true
for any sequence.


Dimitre Novatchev.

We discussed this on the 12/2/2003 telcon
and decided not to change the name of the function.  "empty" is as
imprecise a word as "exists" and it did not seem that a change in the
name of the function would benefit our users.

Accepts decision.

Section 15.1 Functions and Operators on Sequences defines the
functions  zero-or-one(), one-or-more(), exactly-one().

The function definitions are:

   fn:zero-or-one($srcval as item*) as item?
   fn:one-or-more($srcval as item*) as item+
   fn:exactly-one($srcval as item*) as item


The main purpose of these functions is to raise an error if the property
they name is not true for the parameter-sequence. 

Such functions are not necessary and useful, because, had their type been
specified as:

   fn:zero-or-one($srcval as item?) as item?
   fn:one-or-more($srcval as item+) as item+
   fn:exactly-one($srcval as item) as item

then the error would be raised automatically if $srcval was not of the
correct type.

Such automatic errors would be raised for any function when passed
parameters not matching the defined types of its arguments -- therefore
the above three functions are not necessary at all.

Solution: remove the functions fn:zero-or-one(), fn:one-or-more() and
fn:exactly-one()


Dimitre Novatchev

STATUS: 
MHK: http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0280.html
DN: http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0282.html
Closed with no action on 1/19.  Paul Cotton replied.
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0171.html.
There is subsequent mail on this thread.
Pointers to above-referenced mail.
    

The description of the fn:subtract-dateTimes-yielding-yearMonthDuration says
in one place that it "returns the result rounded to contain only years and
months."  But it also says that "If there is a remaining number of days,
they are discarded." 

These two statements seem to contradict each other.  Does it round or not?

Thanks,
Priscilla

STATUS: Response from AM saying text had been changed due to separate
discussion.

Text changed due to previous discussion.

Accepted.

I'm curious why the subtract functions on date/time were changed to 
take the empty sequence but the ones on durations were not. Is this a 
bug or is there a decision behind it?

The ones that can take the empty sequence are:
op:subtract-dates
fn:subtract-dateTimes-yielding-dayTimeDuration
fn:subtract-dateTimes-yielding-yearMonthDuration
op:subtract-times

The ones that cannot are:
op:subtract-dayTimeDuration-from-date
op:subtract-dayTimeDuration-from-dateTime
op:subtract-dayTimeDuration-from-time
op:subtract-dayTimeDurations
op:subtract-yearMonthDuration-from-date
op:subtract-yearMonthDuration-from-dateTime
op:subtract-yearMonthDurations

--Sarah

STATUS: On the 12/02 F&O Telcon we decided to accept Sarah's suggestion and make the change.
We decided this was minor and the WGs had to be informed but did not have to approve.

The F&O Taskforce agreed to make this change on the 12/2 telcon.

  This is a far-reaching proposal and the Working Groups felt that its
  consideration should be postponed until after this document was
  published. This note is to alert readers that such a change may appear
  in future versions of this document.


I would like to add my strong support for this proposal.
Section 9 of F&O has always been one of the most contorted parts of
Xpath2, and simplifying this may go some way to making Xpath2 more
usable. 

David

STATUS: Subsumed by the existing issue on this subject.
This was raised by Mike Kay in
http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0114.html
and Jeni Tennison in
http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0059.html
Response from Jim Melton
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0284.html
On 1/19 agreed to close with no action. 
AM replied: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0394.html
David Carlisle agreed: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0385.html
Jeni Tennisons note above asks for additional duration functions.  Put
on F&O agenda.  Still pending.  See F&O minutes Feb 3, 2004.
Pointers to referenced messages:

fn:normalize-unicode contains a normalization form of
"fully-normalized", but it is not at all clear what this means.

charmod at the point that it defines this term says:

  For plain text (no includes, no constructs, no character escapes) in a
  Unicode encoding form, full-normalization and Unicode-normalization are
  equivalent.

The argument of fn:normalize-unicode is a _string_ so is plian text in
the sense of the above, so the requirements of fully-normalized over NFC
do not apply.

Also the definition of fully-normalized in charmod says

   the text is in ___a____ Unicode encoding form, 

Note that it does not specify which form should be used (probably NFC
makes most sense here so should probaby be specified) but then as noted
above there probably wouldn't be any difference between NFC and
fully-normalized for a string argument, except possibly the latter would
add a space at the start of the string (which is a possible difference,
despite the charmod quote that says these are equivalent...)


David

STATUS: Addison Phillips provided algorithm
http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0198.html
Paul Cotton asked for a normative reference and offered to postpone
until the March meeting. 
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0026.html
Addison Phillips offered agreed to provide a normative reference by March, or earlier. 
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0028.html

STATUS:  Discussed again at Redmond meeting on August 26, 2004.  Decided to 
postpone until stable versions of the Charmod documents are available.

STATUS:  Cannot process now.  Decided to close and re-raise at last call.
See member-only minutes: http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Oct/0066.html

    

There is a normative reference to an earlier charmod draft
 http://www.w3.org/TR/2002/WD-charmod-20020430/ 
however the current draft, is
http://www.w3.org/TR/2003/WD-charmod-20030822/ 

David

STATUS: AM agreed to change but we think Anders replied that change should not be made.
AM replied: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0382.html
DC accepted response: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0383.html
There are follow-up messages on this thread from Paul Cotton.  The
status of the document is unclear.  
Suggest we keep open.

STATUS:  Discussed again at Redmond meeting on August 26, 2004.  Decided to 
postpone until stable versions of the Charmod documents are available.

STATUS:  Cannot process now.  Decided to close and re-raise at last call.
See member-only minutes: http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Oct/0066.html
    

The new definition for normalize-unicode has replaced the "W3C" 
normalization form with the string "fully-normalized".
However, the description states:

"The effective value of the $normalizationForm is computed by removing 
leading and trailing blanks, if present, and converting to upper case.
[..]

- If the effective value of $normalizationForm is "fully-normalized", then 
the value returned by the function is the value of $arg is the fully 
normalized form."

Now, the effective value of $normalizationForm can never be 
"fully-normalized"; while it can be "FULLY-NORMALIZED", as the string is 
made upper-case.

Alberto

Agreed to make the suggested editorial change.

I have commented on previous drafts that this function is unlikely to be
much use in practice as it has far too many arbitrary choices of what
constitutes equality and it ought to be moved to appendix C.

However assuming that it stays here the current definition appears to
have problems with document nodes.

Currently this clause is commented out

  (: if ($parameter1 instance of document-node() and not ($parameter2
  instance of document-node())) then fn:false() else :)


which means that if the first param is a document node and the second a
comment, they will return true if their string values are equal,
however if the same two parameters are given in the other order it will
return false due to
  if ($parameter1 instance of comment() and not ($parameter2 instance of
  comment())) then fn:false() else


so deep-equal isn't symmetric.

Even if that clause is restored, it appears that if both arguments are
document nodes then the test will fall through to:

  else  (: Must be a namespace node by elimination :)
   fn:compare (fn:string($parameter1), fn:string($parameter2)) ne 0

and so the string values of the documents will be compared, which
probably isn't what was intended.


David

    

On May 4 we decided to accept wording suggested by Mike Kay.

The description (possibly copied from C.2.1 eg:value-union) says
 
" ...in an undefined order."

However both the xslt and xquery implementations given preserve the input
order. Either the phrase should be dropped or fn:unordered() should be
used in the implementations.

The equivalent comment in C.2.1 does not have this problem as there the
implementations use fn:distinct-values() so do return things in an 
an implementation dependent (rather than undefined) order.

David

We discussed this on the 12/2/2003 telcon and decided that the
wording was correct since both the implementations use fn:distinct-nodes.

Accepts decision

The signature for string-length is

   fn:string-length($arg as xs:string) as xs:integer

but the description says:

"If the value of $arg is the empty sequence, the xs:integer 0 is returned".

It seems to me that the signature should be changed to be

   fn:string-length($arg as xs:string?) as xs:integer

so that an empty sequence can be recognized as a valid argument

Alberto

Seems like a bug!  I'll take a look.
    

It may be worth noting that (unfortunately) XML 1.1 is planning to
change the white space rules and add x85 and x2028.
This will mean that XSLT using an XML 1.1
parser on a document containing an x85 will see a x10 which will be
normalised by this function, whereas the same expression in an Xquery
query on the same document will see a non-white space character that
will not be normalised (unless Xquery plans to adopt the XML 1.1 rules).

My preferred solution would be to not change the XML white space rules
(A comment has been sent to the XML editor list) but assuming that XML
1.1 does do this, it may be worth adding a note here as it will likely
to be a cause of apparent incompatibility between xslt and xquery.

David

No change needed

Accepts decision

> If any of the code points in $arg is not a legal XML character,

Have the WGs considered dropping this constraint?
This would of course require relaxing the data model to allow such
characters.

It comes up from time to time on XSL list that people are using XSLT to
query XML documents but generating non-xml using
<xsl:output method="text"/>
and so it might be quite natural to allow non-xml characters in the
output.

James Clark's original xt implemtation had a non-standard nxml output
method to achieve this (using specific elements to represent characters
that were linearised as non-xml characters) but given that the function
codepoints-to-string has been added one could use
<xsl:value-of select="codepoints-to-string(5)"/>
for this. It would of course be a serialisation error to output this
using an xml/xhtml output method.

Actually the example "5" would be legal (presumably) in a data model
based on XML 1.1 as XML 1.1 draft only bans character 0 from the C0
controls, only insisting that the others are linearised using numeric
references.

So even if the constraint is not dropped, the phrase "not a legal XML
character" might need to be clarified with respect to applicable XML
version.

David

The F&O taskforce discussed this on
12/2/2003 and decided not to make the change to allow characters that
are not legal XML characters.

We will look into changing the wording to clarify which version on XML
is supported.

For the record, I'm happy enough with that. I thought I would float it
as a suggestion but I don't object to a "no".

The whole "fn: is a function and is mapped to 
|http://www.w3.org/2003/11/xpath-functions| except when you actually use 
it (in which case no prefix is used), and op: looks like a namespace 
prefix but really isn't" is just a mess. It's a symptom of the 
"everything must have a namespace and a URI" disease that has infected 
the W3C for the last few years. Removing the operators namespace URI in 
this draft has just made this more obvious. This whole namespace mess is 
horribly confusing.

Let's face reality: None of the functions or operators are in any 
namespace. The whole idea of putting these in a namespace does not jibe 
with the namespaces spec. Nothing is gained by claiming these functions 
and operators are in a namespace. Talking about the namespace of an 
XQuery function has no more meaning than talking aobut the current king 
of France or the set of triangles with four sides.

The XQuery functions and operators spec will bemuch clearer if it does 
not attempt to place any functions or operators in any namespace. If you 
wish to use the syntax fn: and op: to distinguish functions from 
operators, that's OK. Alternately you could pick a different delimiter 
that does not remind anyone of namespace prefixes. For example, fn# and 
op#. However, fn: and op: should not be namespace prefixes, and in 
reality they never really were.

--
Elliotte Rusty Harold

STATUS: Agreed to close in Tampa.  Norm to respond.

    

Comment 2.8 in XML Schema WG comments on Functions and Operators (below) said:

    The rules for escaping URIs should be aligned across all W3C
    specifications; otherwise, we will drive our users crazy.

    We think that means that you should reference and implement the
    algorithm specified in the XML Linking specification
    ([30]http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators)

There was a similar comment from the i18N WG.

We agreed to align the description with the above algorithm which says
that all characters disallowed in URIs according to RFC 2396 except
for the number sign (#) and percent sign (%).  Thus, the number sign
(#) and percent sign (%) are never escaped.

The forthcoming URI syntax draft
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html adds the number
sign (#) to the list of reserved characters so it seems that it should
be escaped.  This would be at variance with the Linking spec but seems
to be the correct decision.

Also, the linking spec says the square brackets should not be escaped
as they are now allowed in per RFC 2732.  Our spec escapes them.  This
seems to be a bug and needs to be fixed.

Please provide guidance.

All the best, Ashok
   

The WGs agreed on 2004-09-28 that the semantics of fn:escape-uri should be aligned with XLink and the semantics were correct as written  
and that this comment could be closed with appropriate editorial changes.

In section 6.3:
"NaN does not equal itself "

But in the XMLSchema 3.2.5: http://www.w3.org/TR/xmlschema-2/#double
"NaN equals itself but is incomparable with (neither greater than nor 
less than) any other value in the value space. "

I believe this discrepancy exists because most floating point 
operations in XQuery use the IEEE 754 standard. If this is the case, a 
note similar to others referencing IEEE 754 should be added. 
Alternatively, a consolidated section describing when to use IEEE 754 
for operations/comparisons on xs:float and xs:double could be added to 
6.1.

If the WGs agree, we could amplify the note in 6.1 a bit to make this clearer.  For example:

This specification uses IEEE-754 arithmetic for xs:float and xs:double values.
This differs from [XML Schema Part 2: Datatypes Second Edition] which defines
NaN as being equal to itself and defines only a single zero. [IEEE 754-1985] arithmetic, 
however,  treats NaN as unequal to all other values including itself and can produce distinct 
results of positive zero and negative zero. 
(These are two different machine representations for the same [XML Schema Part 2: Datatypes 
Second Edition] value.) The text accompanying several functions discusses behaviour for both positive 
and negative zero inputs and outputs in the interest of alignment with [IEEE 754-1985].

Status section says casting to QName and NOTATION is allowed.  Casting section contradicts this.

The status section is incorrect it should say "construction of xs:QName and xs:NOTATION have been clarified ...".

The description of the fn:concat function says that it "accepts two or more
xdt:anyAtomicType arguments and converts them to xs:string".  I think it
would be more precise to use the term "casts" rather than "converts".

STATUS:  Done.

The return type of the fn:local-name-from-QName function says xs:NCNAME.
This is incorrectly capitalized, it should be xs:NCName.

STATUS: Done.

The description of the fn:ceiling function says "If the argument is less
than zero (0), negative zero (-0) is returned."

I assume that should say "If the argument is less than zero (0), ***and
greater than -1,*** negative zero (-0) is returned."

STATUS: Done.

There is an error in the final example of fn:index-of. 
In my opinion in the attribute value a="red green blue" the the attribute 'a' would atomize to a single string value, not three.

STATUS:  Fixed as per MHK suggestion in http://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0080.html 
to change type of attribute to NMTOKENS.

According to section 6.2 of the 2004-07-23 Working Draft of F&O, "For 
op:numeric-add, op:numeric-subtract and op:numeric-multiply if either 
operand is INF or -INF the result is NaN."

     I believe that statement is not consistent with IEEE-754. Multiplying 
a zero value by an Infinity, adding Infinities that have opposite signs, 
or subtracting Infinities that have the same sign should result in NaN. In 
addition, adding, subtracting or multiplying an Infinity and a NaN should 
result in a NaN.  Other combinations involving an operand with infinite 
magnitude will result in an infinity with the appropriate sign.

STATUS:  Fixed.

General		
Editorial	

Examples with op: functions: Should use actual operator since function
is not directly available for user. Otherwise it implies that users
could type this example.

STATUS:  On the 2004-05-26 telcon the WGs agreed to make this change.

    

Section 15.3.2 fn:avg	
Editorial/Technical	

What is the result of avg( (inf, -inf) )?
Please add this as example.

STATUS:  Example added.

    

Section 15.3 Aggregators	
Editorial/Technical	

Can sequence contain xdt:untypedAtomic? Mention it in intro.

STATUS:  Done!

    

Section 15.1.13			
Editorial/Technical

Please give semantics for NaN.

STATUS:  This is covered by the rules given.

    

General		
Editorial	

Add link to specific FS section for special type rules for all functions
with special typing rules (this also assures that we have them defined
in the Formal Semantics).

STATUS:  Done!

    

Section 14.1.3		
Editorial	

What does "attribute/element node without QName" mean? Please clarify
wording or remove.

STATUS:  Fixed in response to another comment.

    

Section 9.2		
Editorial	

Remove the Note about XSD potentially including the new duration types.
XSD 1.0 is not adding these types, therefore we cannot remove them from
XQuery 1.0.

STATUS:  Note has been removed.

    

Section 7.4.3.1 fn:substring	
Editorial	

In F&O substring function
[http://www.w3.org/TR/xquery-operators/#func-substring] examples, 0E0.0
is not valid double format... should be 0E0.

STATUS:  Fixed as a result of another comment.

    

Sections 6.2 and others		
Editorial	

We reiterate our comment submitted during our first last call review at
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0325.html
about rewriting the operator mapping to have op: functions allow to take
empty sequences or at least call out where the empty sequence behaviour
is defined. See also
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0190.html
. 

    

The WGs agreed to add wording to explain the situation.

Section 1.7 
Editorial

The spec says:"The namespace prefix for these functions and datatypes
can vary, as long as the prefix is bound to the correct URI.

The URIs of the namespaces are:

http://www.w3.org/2001/XMLSchema for constructors

http://www.w3.org/2003/11/xpath-functions for functions.

http://www.w3.org/2003/11/xpath-datatypes for the datatypes."

It is not clear what the meaning of the URIs are. The schema and the
xpath-datatype namespace both are used for the types and the
constructors. It would be better to say 

" The following prefixes and namespace URIs are being used:

The prefix xs is bound to http://www.w3.org/2001/XMLSchema.

The prefix fn is bound to http://www.w3.org/2003/11/xpath-functions.

The prefix xdt is bound to http://www.w3.org/2003/11/xpath-datatypes."

STATUS:  Fixed as a result of an earlier message.

    

(IBM-FO-042): Section 15.4.4 (fn:doc): Result type in signature is not a 
valid SequenceType. Change "document?" to "document-node()?".

--Don Chamberlin

STATUS:  Done.

    

(IBM-FO-041): Section 15.3.5 (fn:sum): Second paragraph says that "The 
items in the resulting sequence may be reordered in an arbitrary order." I 
don't think this is relevant to the fn:sum function.

--Don Chamberlin

STATUS:  Done.

    

(IBM-FO-040): Sections 15.3.3 (fn:max) and 15.3.4 (fn:min): In both of 
these sections, all the examples except the first one are syntactically 
invalid because they pass many arguments to a function that accepts only 
one argument. This needs to be fixed by enclosing the argument sequence in 
parentheses. Also, in each of these sections, the fifth bulletted example 
is missing a right-parenthesis at the end of the function parameters. 
Also, the third bulletted example in each section claims it can return 
either an integer or a double. But the text says that all numeric values 
are promoted to a "single common type", implying that (for example) max(5, 
5.0e0) will always be of type xs:double.

--Don Chamberlin

STATUS:  Done.

    

(IBM-FO-039): Sections 15.3.3 (fn:max) and 15.3.4 (fn:min): These sections 
say that "$arg must contain only items of a single type or one of its 
subtypes for which the gt operator is defined." This would seem to prevent 
(for example) finding the max of two values of type xs:long and xs:short, 
even they are both derived from xs:integer which has a gt operator. It 
would also prevent finding the max of two values whose types are both 
derived from xs:string. I do not think this is intended. I think you mean 
to say that "all the items in $arg must either be numeric or be derived 
from a common base type that has a gt operator." Similarly, Section 15.3.5 
(fn:sum) says that "The input sequence must contain items of a single type 
or one of its subtypes." Again, this would prevent finding the sum of two 
values of type xs:long and xs:short. The rule should be restated to accept 
all numeric values.

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-037): Section 15.1.14 (fn:unordered): The summary begins "This 
function takes a sequence, or more typically, an expression that evaluates 
to a sequence ...". This implies that a "sequence" is somehow different 
from "an expression that evaluates to a sequence." Actually there is no 
difference. The phrase beginning "or more typically" should be deleted.

--Don Chamberlin

STATUS: On 8/23/2004 the joint WGs decided to accept the wording recommended by
Michael Rys in http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0099.html marginally amended to read "Returns the items of $sourceSeq in a non-deterministic order."

    

(IBM-FO-035): Section 14.1.4 (fn:number): The summary paragraph says that 
if the context item is not a node, NaN is returned. The third paragraph 
seems to contradict this by saying that if the context node is atomic, its 
value is converted to xs:double. On closer reading the confusion only 
increases: how can a node be atomic? Then the fourth paragraph says that 
in the case of a node with an atomic type, its "value" is converted to 
xs:double. Does this refer to the node's typed value or its string value?

--Don Chamberlin

STATUS:  Wording corrected.

    

(IBM-FO-033): Sections 10.2.4 (fn:get-namespace-uri-for-prefix) and 10.2.5 
(fn:get-in-scope-prefixes): Both of these functions have signatures 
containing types that are not valid SequenceTypes ("element" should be 
element()".)

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-031): Section 9.7.2, 
fn:subtract-dateTimes-yielding-dayTimeDuration(): This section should say 
that its function backs up the subtract operator on dateTime values (but 
it should still be in namespace fn: rather than op:).

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-030): Section 9.7, Adding and Subtracting Durations ...": This 
section should have a more general title, since some of its functions do 
not operate on durations (for example, op:subtract-dates).

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-029): Section 9.6.2, "fn:adjust-date-to-timezone": In this 
section, the "summary" paragraph is followed by 7 rules. Rules 5 and 7 
seem redundant. Both rules deal with the case where $timezone is not 
empty. Probably the last rule was intended to deal with the case where 
$arg has a timezone and $timezone also contains a timezone. The last rule 
should be rewritten to correctly describe this case.

--Don Chamberlin

STATUS:  Fixed in response to an earlier comment.

    

(IBM-FO-028): Section 9.5, "Arithmetic Functions on Durations": In the 
table at the beginning of this section, op:multiply-yearMonthDuration() 
and three other functions are said to take operands of type xs:decimal. 
But in the actual signatures of these functions, the operands are 
specified as xs:double rather than xs:decimal.

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-027): Section 9.4.18, fn:get-hours-from-time(), contains four 
bulleted examples, and states that the last example returns 6. Please take 
a close look at this. I think the correct result for this example is 20.

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-026): Section 9.4, Component Extraction Functions, says "To get 
the value of a component from the normalized value, the (value) must first 
be adjusted to UTC or timezone Z." This statement seems backward. Isn't it 
true that the normalization process converts a local time into a UTC time? 
Then how can the value be "adjusted to UTC" if it is already stored in 
UTC? Do you really mean the opposite (value is converted from UTC into the 
local timezone)? (This would seem to be consistent with the examples in 
this section.)

--Don Chamberlin

STATUS:  The component extraction functions now used the localized values.
This comment is, thus, moot.

    

(IBM-FO-025): Section 9.3.8, op:dateTime-equal(), would benefit from an 
example of comparing two dateTimes that are equal although their 
normalized values are in different days. For example, what is the result 
of op:dateTime-equal(xs:dateTime("2002-04-02T23:00:00-04:00"), 
xs:dateTime("2002-04-03T02:00:00-01:00"))? (I predict the answer is True.)

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-023): In Section 7.5.4, fn:substring-before(), paragraph 3 says 
that if $arg2 is the zero-length string, the function returns the 
zero-length string. But the example in the second bullet has a zero-length 
$arg2 and it does not return the zero-length string. Is this a bug in the 
example?

--Don Chamberlin

STATUS:  Fixed as the result of another comment.

    

(IBM-FO-022): Section 7.3.2 says that fn:compare() with the second 
signature backs up "eq" and other value comparisons on strings. Actually, 
the first signature is used (since the value comparison operators have no 
way to specify a non-default collation).

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-021) Editorial comments on Functions and Operators:

(a) Section 1, Introduction: "as well as the two datatypes defined in 
Section 1.5". Actually, there are three datatypes defined in this section, 
which should have a more general title.

(b) Section 1.2, Function Signatures and Descriptions: "the following four 
functions signatures" should be "the following four function signatures" 
(function is not plural).

(c) Section 1.2, Function Signatures and Descriptions: In the paragraph 
beginning "For most functions", "a initial paragraph" should be "an 
initial paragraph".

(d) Section 1.3, Namespace Terminology: This section could be merged with 
Section 1.8, Terminology.

(e) Section 1.4, Type Hierarchy: First paragraph lists the type xs:IDREFS 
twice in the same enumeration (once with a colon and once without).

(f) Section 1.5.2, xdt:untypedAtomic: "a XML Schema" should be "an XML 
Schema".

(g) Section 6.4.1, fn:abs(): says "the type of the return is the parent 
numeric type." The term "base type" would be better than "parent type". 
Same comment applies to sections 6.4.2 (fn:ceiling), 6.4.3 (fn:floor), 
6.4.4 (fn:round), and 6.4.5 (fn:round-half-to-even).

--Don Chamberlin

STATUS:  Fixed except for (e) which requires some thought.

    

(IBM-FO-016) Section 6.4.2, fn:ceiling: Says "If the argument is less than 
zero but greater than or equal to -0.5, then negative zero is returned. 
This seems to be a cut-and-paste error. The value -0.5 doesn't have 
anything to do with the fn:ceiling function.

--Don Chamberlin

STATUS:  Bug.  Fixed.

    

(IBM-FO-014) Section 5.2, Constructor Functions for User-Defined Types: In 
the first paragraph, delete "globally-defined". It adds nothing since all 
atomic types are globally-defined. Also delete "by restriction". It adds 
nothing since by restriction is the only way to define a derived atomic 
type. However, you need to note that only atomic types that are in a 
namespace have a constructor function, since every function is required to 
be in a namespace. There are no functions that are in no namespace. For 
this reason, the second paragraph should be deleted becauses it refers to 
functions that cannot exist.

Also, in the last paragraph of this section, "schema that is bound to the 
prefix" should be "namespace that is bound to the prefix".

--Don Chamberlin

STATUS:  Wording changed.

    

(IBM-FO-013) Section 5.1, Constructor Functions for Built-in Types: I 
don't think the note under xs:QName adds anything. All the constructors 
are defined by references to casting semantics, not just this one.

--Don Chamberlin

STATUS: Semantics of this constructor changed.  Note removed.

    

(IBM-FO-009) Section 1.7, Namespaces and Prefixes, needs the following 
changes: 

(a) Section claims that all functions defined in this document are in 
three namespaces. Actually it should be four (xdt: contains some 
constructor functions).

(b) The first paragraph and the last paragraph both say that fn: functions 
are visible to users and op: functions are not. There's no need to say 
this twice.

(c) In the bullet list, it would be helpful to list the pre-assigned 
prefixes as well as the namespace URIs (as in the XQuery book, section 
4.4).

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-007) Section 1.5, xdt:anyAtomicType and xdt:untypedAtomic: This 
section needs a more general name, such as "Generic Types", especially 
since it now includes three types rather than two.

--Don Chamberlin

STATUS:  Heading changed.

    

(IBM-FO-005) Section 1.4, Type Hierarchy and throughout the whole 
document: Please replace xdt:untypedAny with the new name xdt:untyped as 
agreed at the working group meeting on 11/5/03.

--Don Chamberlin

STATUS:  Done!

    

(IBM-FO-004) Please improve the following cross-document references:

(a) Section 1.2, Function Signatures and Descriptions: Paragraph beginning 
"As is customary" refers to XQuery Section B.1 (Type Promotion). A better 
reference would be XQuery Section 3.1.5 (Function Calls).

(b) Section 1.5.1, xdt:anyAtomic Type: contains a reference to XQuery 
Section 3.12 (Expressions on SequenceTypes). A better reference would be 
to XQuery Section 2.4.3 (SequenceType Syntax). Same comment applies to 
Sections 1.5.2 (xdt:untypedAtomic) and 1.5.3 (xdt:untypedAny).

--Don Chamberlin

STATUS: Fixed.

    

(IBM-FO-003) Section 1.2, Function Signatures and Descriptions: Please 
make the following changes to the paragraph beginning "In this notation":

(a) Paragraph claims that each parameter has a non-normative name "used to 
describe the function's semantics". Please delete this phrase. The name of 
a parameter is not used to describe the function's semantics.

(b) Paragraph says "In most cases, the dynamic type returned by the 
function is the same as its static type." Please delete "in most cases". 
This is either a rule or it is not. The rule should say that the dynamic 
type of the return value is always the static return type or derived from 
the static return type.

(c) Paragraph says says the types "node" and "item" are indicated as 
"node()" and "item()". No need to treat these types as special cases. 
Instead, please state that all parameter types and return types are 
specified using the SequenceType notation defined in Section 2.4.3 of the 
XQuery book. This is a more comprehensive statement, and covers the whole 
notation including occurrence indicators, etc.

Similarly, the last three paragraphs of Section 1.2 attempt to explain 
certain specific aspects of SequenceType notation. This should be covered 
by the general statement that all parameter types and return types are 
specified using the SequenceType notation. It's OK to include some 
examples that are of interest in function signatures, such as illustrating 
the difference between a function that takes no parameter and a function 
that has a parameter that accepts the empty sequence.

--Don Chamberlin

STATUS:  Fixed.

    

(IBM-FO-002) Section 1.1, Function Overloading: Should define what we mean 
by "function overloading". Specifically, should state that multiple 
functions with the same name but different numbers of parameters are 
permitted.

--Don Chamberlin

STATUS:  Fixed.

    

The F+O spec contains hyperlinks to the XQuery specification to explain
concepts such as base URI, atomization, etc.

These links should be to the XPath specification, to avoid creating any
impression that they apply only when the relevant functions are used
from within XQuery.

Michael Kay

STATUS:  Done.

    

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Hello,

     Following are comments on F&O that we believe to be editorial in 
nature.


------------------------------------------------------------------

Section 1.4

The type hierarchy diagram should include namespace nodes.  A namespace 
node is a distinct type of node in the Data model, so omitting it from the 
diagram is just confusing.  It also needs to be included in the last table 
in this section.

------------------------------------------------------------------

Section 1.4

In the third sentence of the first paragraph, xs:IDREFS is mentioned 
twice.

------------------------------------------------------------------

Section 1.4

In the type diagram, the line that connects xs:IDREFS, xs:NMTOKENS, 
xs:ENTITIES to xs:anySimpleType is also joined to the line from 
xdt:anyAtomicType to xs:anySimpleType.  The line from xdt:anyAtomicType 
also leads to item.  This makes it look like xs:IDREFS, et al. are 
subtypes of item, which is not the case.

The two lines into xs:anySimpleType from its subtypes should be separated 
to avoid that potential confusion.

------------------------------------------------------------------

Section 1.5

The title of this section should include xdt:untypedAny, for completeness.

------------------------------------------------------------------

Section 1.8

In the definition of "stable", "fn:current-date" should be 
"fn:current-date()", in order to be consistent with other functions in the 
list.

------------------------------------------------------------------

Section 3

The first paragraph indicates that errors must be raised through a 
reference to the fn:error function.  Some rationale as to why this is 
necessary should be provided.

------------------------------------------------------------------

Section 3.1

The example uses the prefix "xdt" for an F&O error, but Appendix D uses 
the prefix "err".

------------------------------------------------------------------

Section 4.1

The example indicates that if the first argument to fn:trace is of type 
xs:decimal, with the value 124.84, the string "124.84" is put into the 
trace data set.  However, the description of the function does not 
indicate that any items in $value are converted to xs:string.  Either the 
description of the function or the example needs to be corrected.

------------------------------------------------------------------

Section 5.1

In third sentence of the paragraph following the xs:unsignedInt example 
box, "that had a value equal to" should be "that had a typed value equal 
to".

------------------------------------------------------------------

Section 5.1

In fourth sentence of the paragraph following the xs:unsignedInt example 
box, "'atomize' the node to extract its value" should be "'atomize' the 
node to extract its typed value".

------------------------------------------------------------------

Section 7.1

In the second note, "is the of XML characters" should be "is the number of 
XML characters".

------------------------------------------------------------------

Section 7.3.1

In the first sentence of the second paragraph, "that that" should be 
"that".

------------------------------------------------------------------

Section 7.3.1

The seventh paragraph introduces the concept of a system defined default 
collation.  The term "system defined" is never defined.  Should this be 
"implementation dependent" or "implementation defined", instead?

------------------------------------------------------------------

Section 7.3.1

The second item in the numbered list indicates that fn:contains, et al. 
use the Unicode code point collation if no collation is explicitly 
specified.  This should provide some rationale.

------------------------------------------------------------------

Section 7.5

The last paragraph of this section ends "the system may reject it."  The 
term "the system" is not defined anywhere.  This should probably be "the 
processor".

------------------------------------------------------------------

Sections 7.5.1.1, 7.5.2.1, 7.5.3.1

"Unicode default collation" should be "Unicode code point collation".

------------------------------------------------------------------

Section 8.3.1.1

The following example would be helpful:

fn:not("false") returns false

------------------------------------------------------------------

Section 9.4.16.1

The second call to fn:get-day-from-date should return 1 rather than 01.

------------------------------------------------------------------

Section 9.4.18.1

In the fourth example, the result of evaluating

 fn:adjust-time-to-timezone(xs:time("01:23:00+05:00"),
                            xdt:dayTimeDuration("PT0H"))

should be the xs:time value 20:23:00-00:00.  The result of applying 
fn:get-hours-from-time to that value should be 20, rather than 16.

------------------------------------------------------------------

Section 9.6.1

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.6.2

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.6.2

The last paragraph before the examples begins, "If $timezone is not the 
empty sequence. . . ."  For the sake of clarity, this should probably be 
"If $arg has a timezone component and $timezone is not the empty sequence. 
. . ."

It's not strictly necessary to mention $arg in this paragraph, but it is 
not necessary to mention it in the previous paragraph either.  To mention 
it in one, but not the other is just confusing.

------------------------------------------------------------------

Section 9.6.3

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.7.1

The third sentence of this section indicates that the difference between 
two values of type xs:dateTime can be viewed as the sum of an 
xdt:yearMonthDuration and an xdt:dayTimeDuration.  The reader might be led 
to believe that fn:subtract-dateTimes-yielding-dayTimeDuration yields the 
second part of that sum, but in fact it does not - at least not directly. 
This should be clarified.

------------------------------------------------------------------

Section 9.7.3.1

As was done with xs:subtract-times, a second example involving a value 
with no timezone and a value with an explicit timezone should be shown. 
For instance,

If the evaluation context provides an implicit timezone value of
+05:00, op:subtract-dates(xs:date("2000-10-30"),
                          xs:date("1999-11-28Z")) returns an
xdt:dayTimeDuration value corresponding to 336 days 

------------------------------------------------------------------

Section 9.7.11.1

Some other helpful examples:

op:subtract-yearMonthDuration-from-date(xs:date("2000-02-29"),
                                   xdt:yearMonthDuration("P1Y"))
returns the xs:date whose normalized value is Feb 28, 1999

op:subtract-yearMonthDuration-from-date(xs:date("2000-10-31"),
                                   xdt:yearMonthDuration("P1Y1M"))
returns the xs:date whose normalized value is Sep 30, 1999

------------------------------------------------------------------

Section 12.1

In the second paragraph, change "may" to "can" to avoid confusion with the 
RFC term.

------------------------------------------------------------------

Section 14.1.1

The seventh paragraph uses the words, "is chosen arbitrarily."  That 
should be changed to "is chosen in an implementation-dependent manner" or 
something similar.

------------------------------------------------------------------

Section 14.1.1

The eighth paragraph states, "If there are several such namespace nodes, 
it chooses one of them arbitrarily."  The clause "it chooses one of them 
arbitrarily" should be changed to "which is chosen is 
implementation-dependent."

------------------------------------------------------------------

Section 15.3.4

In the second note, "fn:max" should be "fn:min".  In addition, "lt" should 
probably be "gt".

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

    

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 7.3

The numbered list in this section indicates that the collation that is 
used for a function like fn:compare is:  any collation specified as an 
argument to the function; if none is specified, the default collation from 
the static context; or if there is no default collation in the static 
context, the Unicode code-point collation.

However, the paragraph preceding this list admits the possibility of a 
"system defined default" collation.  That possibility needs to be included 
in this list.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

STATUS:  Wording changed.  Comment no longer applies.

    

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 3

The second paragraph indicates that errors are identified by xs:QNames in 
the namespace identified by the xdt prefix.  However, the list of errors 
that appears in appendix D uses a prefix of err, which is the same prefix 
used by XPath, and which is not in any namespace.

If these errors really are in a namespace, a single consistent prefix 
needs to be used.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

STATUS:  This was a typo and has been fixed.

    

SECTION 1.7 : Namespaces and prefixes

There are several forward references to the namespaces defined in
this section.  This is avoidable, by simply moving this
section prior to the first use of any namespaces, which I believe
would place it prior to section 1.4 "Type hierarchy".  You might also consider combining this section with section
1.3 "Namespace terminology".

- Steve B.

STATUS:  Fixed.  Thanks!

    

SECTION 1.7: Namespaces and prefixes

This section describes three namespaces, which have distinct URIs, prefixes and purposes.  It would be great to have a table that summarizes all of this.  As it is right now, in the middle of the section you have a bulleted list that pulls together two out of three of these ingredients (the namespace URI and the purpose) but not the prefix.  The correct prefixes are certainly deducible from other material in this section, but why not just put all the information together in one convenient table?

- Steve B.

    

SECTION 2.5: fn:document-uri

In Section 2.5, "fnd:document-uri", we find the text "as defined by the accessor function dm:document-uri in Section 6.1 base-uri Accessor."  It seems obvious that this is a typographical error, since the Functions & Operators section is named "document-uri"; we believe that the intent was to reference a section in the Data Model document dealing with dm:document-uri. 

However, there is no section at all in the Data Model document whose title is "base-uri Accessor"!  In fact, the only uses of the term "document-uri" in the Data Model occur in Section 6.1.2, "Accessors", in which dm:document-uri appears as the third of "Three additional accessors". 

Perhaps the wording in F&O should be changed to read "as defined by the accessor function dm:document-uri in Section 6.1.2 Accessors." or perhaps to "...Section 6.1, Document Nodes". 

This is slightly more than the editorial comment that we have filed on F&O Section 2.5, "fn:base-uri", but it also raises the same concerns that additional references to the Data Model document may be incorrect. 

- Steve B.

STATUS.  Wording changed.

    

SECTION 2.4: fn:base-uri

In Section 2.4, "fnd:base-uri", we find the statement "as defined by the accessor function dm:base-uri for that kind of node in Section 6.1 base-uri Accessor."  The text "Section 6.1 base-uri Accessor" is a link. 

However, when the link is followed, it takes one to Section 5.1, "base-uri Accessor" in the Data Model document. 

The correction is obvious: replace "6.1" with "5.1".  However, this raises concerns that other references to the Data Model may be similarly incorrect. 

- Steve B.

STATUS:  Should be fixed with next build.

    

SECTION 7.5.1 : fn:contains

Second paragraph, second sentence: "If the specified collation 
is unsuitable...".  What is unsuitable?  Probably what you are
getting at is that the collation must support collation units.
If that is the criterion, the sentence would be more specific if
it said "If the specified collation does not support collation
units...".

- Steve B.

STATUS:  Wording changed.  Thanks!

    

SECTION 7.5 : Functions based on substring matching

Regarding collations that do not support collation units, the 
last sentence before the table in this section says "Such a 
collation may fail, or give unexpected results and the system 
may reject it."

What is meant by "the collation may fail"?  The collation is 
not a thing that can fail; it is just a subroutine that is called
with certain defined arguments and mechanically gives a result.
Perhaps you mean "the collation may not do what you expect it to
do", but that is expressed better by the next clause, "or give
unexpected results".  Perhaps you mean "the collation may go into
an infinite loop" which I guess would be a kind of failure, though
based on my understanding of collations, this seems remote.
More likely, you do not mean "the collation may fail", you mean
"the function will not achieve its design goal."

Moving on, what is meant by "the system may reject it"?  First, who is "the system"?  Is it the XQuery processor?  Second question: what does "reject" mean?  Does it mean "raise an exception"?  If not, what
happens when the system rejects it?

- Steve B.

STATUS:  Wording changed.  Thanks!

    

SECTION 1.8: Terminology

"Implementation defined" is not hyphenated, and probably should
be (confer "implementation-dependent" immediately following).

- Steve B.

STATUS:  Fixed.  Thanks!

    

SECTION 15.1.9 : fn:distinct-values

The first paragraph says "Values that cannot be compared, i.e. the
eq operator is not defined for their types, are considered to be
distinct."  Later it says "Values of type xdt:untypedAtomic are
compared as if they were of type xs:string."  It is not clear
whether one should use the implicit cast from xdt:untypedAtomic
to xs:string before or after applying the rule that values of
incomparable types are always distinct.  Example: given an
untypedAtomic of value "abc" and an xs:string of value "abc",
if we first apply the rule that incomparable values are distinct,
then we conclude that these are two distinct values.  On the
other hand, if we cast the xdt:untypedAtomic, making it into
an xs:string before comparing, then the two values are equal
and only one of them is retained in the result.

If the second interpretation is the correct one, then what is the
type of the "abc" value that is retained in the result?  Is it
xdt:untypedAtomic, is it xs:string, or is it
implementation-dependent?

The simplest resolution to this might be to say that the first
step is to form a sequence derived from the input sequence by
replacing every xdt:untypedAtomic by the result of casting it to
xs:string.  Then throw out duplicates from this derived sequence.


- Steve B.

STATUS:  Steve is correct.  Changed wording to make treatment of
xdt:untypedAtomic values clearer.

    

SECTION 15.4.2: fn:id

fn:id and fn:idref are node related functions. It would be 
clearer to define them in section 14 "Functions and Operators on Nodes". We can have cross references in 15.4 mentioning that those two functions will generate sequences.

- Steve B.

STATUS:  The editors decided not to make this change.

    

SECTION 15.2.2: op:union

"Summary: Constructs a sequence containing every node that occurs in the values of either $parameter1 or $parameter2, eliminating duplicate nodes. Nodes are returned in document order. "
If $parameter1 is empty sequence and $parameter2 has duplicate nodes and is not in document order, should we just return $parameter2 as it is, or normalize $parameter2 first, i.e. eliminating duplicate nodes and sorting in document order?

op:intersect and op:except need clarification too.

- Steve B.

    

The WGs agreed to add clarifying wording.

SECTION Annex D: Error Summary

Some error codes (e.g., FOAR0001, division by zero) are accompanied by a natural language explanation of the code (the circumstances under which the error is raised, done informally).  However, most of them are not. 

Consistency is highly desirable, and it seems most useful to readers to achieve consistency by adding such explanations for all codes that do not have them yet. 

- Steve B.

STATUS:  The WGs decided in principle on 2/28/2005 to make this change.

    

SECTION 17.10: casting to date and time

Rules 2 and following do not have "otherwise" cases, which 
presumably would raise an error.  You need these "otherwise"
rules to specify which error.  This might be averted by 
refering to the table in 17.1 prior to all existing rules,
and saying that whenever there
is an N in that table, then such-and-such an error is raised.

- Steve B.

STATUS:  Fixed as per Steve's second suggestion.

    

SECTION 17.10: casting to date and time

The definition of eg:convertTZtoString could be simplified by
using eg:convertTo2CharString, as follows:

let $tzhString := eg:convertTo2CharString (fn:abs($tzh))
let $tzmString := eg:convertTo2CharString (fn:abs($tzm))


- Steve B.

STATUS:  Fixed.

    

SECTION 17.10: casting to date and time types

Step number 1 defines CTZ as the current time zone.
This quantity is never used in any subsequent step and so its
definition can be deleted.  Its use would be to default the
timezone, but in fact the timezone is always defaulted from
the timezone of the source value.

- Steve B.

STATUS:  Fixed.

    

SECTION 17.10: casting to date and time types

The definition of eg:convertSecondToString defines $intLength
as a value of type xs:string.  I think you want to wrap 
fn:length around the entire right hand side of the let statement defining $intLength.


- Steve B.

STATUS:  Fixed.

    

SECTION 17.10: casting to date and time types

First para, last sentence: "...converting an xs:integer year value
requires converting to xs:string with 
four or more characters preceded by a minus sign if the value
is negative."  The scope of "if the value is negative" is not
clear.  For correctness, it must apply only to the phrase
"preceded by a minus sign", not to "with four or more characters..."
or "to xs:string ..." or "converting an xs:integer year...".
To fix this, insert a comma after "four or more characters".

- Steve B.

STATUS:  Done.

    

SECTION 17.9: casting to duration types

The second and third bullets describe how to cast between 
xdt:yearMonthDuration and xdt:dayTimeDuration.  The second bullet
tells how to cast "...a type derived from xs:duration..."
(which might be xdt:dayTimeDuration) to xdt:yearMonthDuration.
(The result is P0M).  Similarly, the third bullet tells how to 
cast from xdt:dayTimeDuration to xdt:yearMonthDuration
(the result is PT0S).  This contradicts the table in section
17.1, which says that these casts are not possible.

This could be fixed in several ways:

1. The description of the table in section 1 could be changed.
Currently it says that "N indicates that there are no supported
conversions".  As worded, this sounds merely descriptive
rather than prescriptive.  The description could be changed to read 
"N indicates that the conversion results in an error" (though 
it would still be necessary to specify which error).

2. The second and third bullets could be reworded to specifically
exclude xdt:yearMonthDuration and xdt:dayTimeDuration, respectively,
and types derived from them.

3. The second and third bullets could be removed entirely.
In that case casting to xdt:yearMonthDuration and 
xdt:dayTimeDuration would fall under the general guidelines in
17.4 "Casting within a branch of the type hierarchy", meaning 
that their pattern facets would have to be satisfied in order for
the cat to succeed.

4. The second and third bullets could be reworded to raise an 
error if the components to be discarded are not already 0 in 
the source.  Though this would still permit casting the zero
values of xdt:yearMonthDuration and xdt:dayTimeDuration to 
one another, so the table would have to say that the conversions
may succeed.

- Steve B.

Fixed as per suggestion 2.

SECTION 17.9 : casting to duration types

Fourth bullet, casting from xdt:yearMonthDuration or 
xdt:dayTimeDuration to xs:duration, it is not necessary to
cast SV to string before casting to duration.  The source
value is already a duration; all you have to do is change the
type annotation on it, as explained in section
17.3 "Casting from derived types to parent types".

 


- Steve B.

    

SECTION 17.9: casting to duration types

The introductory paragraph says that this section applies
"when a value of any primitive type is cast to xs:duration,
xdt:yearMonthDuration or xdt:dayTimeDuration".  The fourth
bullet talks about "When ST is xdt:yearMonthDuration or
xdt:dayTimeDuration...".  But this case cannot arise, based 
on the introductory paragraph, because such an ST would not be
a primitive type.

- Steve B.

STATUS:  Wording changed.

    

SECTION 17.4: casting within a branch of the type hierarchy

Last paragraph, the hyperlink to 17.8 "Casting to numeric types"
can be replaced by a link to the more specific reference
17.8.4 "Casting to xs:integer".


- Steve B.

STATUS:  Fixed.

    

SECTION 17.1: casting from primitive types to primitive types

Last sentence of second para: "There are no values with the 
type annotation xs:anySimpleType" at runtime.  In that case,
can't you eliminate the references to xs:anySimpleType in 
the remainder of section 17?  See 17.8.1 last bullet,
17.8.2 last bullet, 17.8.3 last bullet, and 17.8.4 last bullet.

- Steve B.

STATUS:  Done.

    

SECTION 17.1: casting from primitive types to primitive types

The first sentence claims that "This section defines casting 
between the 19 primitive types...as well as xdt:untypedAtomic
and the two derived types xdt:yearMonthDuration and 
xdt:dayTimeDuration."  Actually, all this section does is 
classify whether such casting is possible, impossible, or 
maybe possible.  The rules for how to do it when it is possible
are not present in this section.  It would be better if the 
first sentence read "This section summarizes when it is permitted
to cast between ...".  Or the first sentence would become true
if you moved sections 17.2 through the end of 17 into
subsections of 17.1

- Steve B.

STATUS:  Wording changed.  Thanks!

    

SECTION 1.6: xs:dateTime, xs:date, xs:time

You define a normalized value and a localized value, and give 
two examples.  Each example uses the phrase "...has a value...".
Are these examples of normalized value or
localized value?  Whichever, please also state what the other value
is as well.

- Steve B.

STATUS:  Good suggestion!  Fixed.

    

SECTION 1.4: type hierarchy

The tables do not stick to the strict indenting rule you have
described for some of the deeply derived numeric types.
You have stacked up xs:short beneath xs:int, for example.
At first I thought it was because you wanted to keep it all 
inside a printout width, but then I noticed that you did 
correctly indent xs:NCName and its subtypes, even though this
overflowed my printer's page width.


- Steve B.

STAUS:  Bug!  Fixed.

    

SECTION 1.4: type hierarchy

The tabular presentations would fit on a normal width printout
if you used a normal indented outline style with 
reasonably narrow indents, instead of treating the width of the
largest subtype as the width of an indent.  

- Steve B.

STATUS:  The WGs decided in principle on 2/28/2005 to make this change.

    

SECTION 1.2: function signatures and descriptions

It says "some functions accept the empty sequence as an argument
and some may return the empty sequence.  This is indicated...
with a question mark: "?"..."  Actually, it may also be indicated
by an asterisk "*", for example, fn:codepoints-to-string or
fn:string-to-codepoints.  
Since you discuss asterisk in a 
subsequent paragraph, you might consider rearranging the order
of these paragraphs.  Another solution is to change the 
first sentence of this paragraph to more accurately represent
what a question mark does.  Yet another solution would be to say
that the type notations follow the syntax and semantics of 
SequenceType.


- Steve B.

    

SECTION 1.2: Function signatures and descriptions

The description of the pseudotype "numeric" gives an example 
showing how to expand into four actual types.  This example is
followed by the sentence "Similarly, for return types".
This sentence is not at all clear.  You cannot mean

fn:numeric-function(...) as numeric

is equivalent to four signatures

fn:numeric-function(...) as xs:integer, etc., because that would
be ambiguous when it comes to determining the static type of the
function.  What I suspect you mean is

fn:numeric-function($arg as numeric) as numeric

expands into four signatures, each of which has the same type 
for the $arg and the return type.  If this is what you mean, please
say so.  Note that you must also deal with the case where there
is more than one argument.  

- Steve B.

    

SECTION 17.8.1: casting to xs:float

Third bullet, first and second subbullets refer to "the maximum
xs:float value" and "the minimum xs:float value".  Aren't 
these values +Inf and -Inf?  I think you mean to exclude +Inf
and -Inf from these statements.

- Steve B.

STATUS:  Fixed.

    

SECTION 9.4.13: fn:get-timezone-from-dateTime

It says "Returns the timezone component of $arg.
The result is an xdt:dayTimeDuration...".  This is not
quite correct, since the return type is "xdt:dayTimeDuration?" .
What you mean is, "Returns the timezone component of $arg, if any.
If $arg has a timezone component, then the result is ....
Otherwise the result is ()."  Similar remarks apply to
9.4.17 fn:get-timezone-from-date and 9.4.21 
fn:get-timezone-from-time.

- Steve B.

STATUS: Fixed.

    

SECTION 9.2.1.3: canonical representation 

The algorithm is sufficiently clear for positive durations.
For negative durations, the world is not agreed on what the 
remainder is when dividing a negative number by a positive number.
The solution is to first take the absolute value of the duration,
then divide by 12 to get the absolute number of years and months,
and finally prepend a minus sign if the input was negative.
Similar remarks apply to section 9.2.2.3.


- Steve B.

    

SECTION 6.2.6 : op:numeric-mod

last bullet for xs:float and xs:double, it says "Division is 
truncating division, analogous to integer division, not
[IEEE 754-1985] rounding division."  But there is more than one
way to perform truncating division.  For example, 2.0/3.0
can be truncated to 0, 0.6, 0.66, 0.666, etc.  Judging by your
example, what you mean is "truncate to an integer after the 
division. 

- Steve B.

STATUS:  Fixed.

    

SECTION 6.2.5: op:numeric-integer-divide

The statement "...ignoring any remainder..." is not helpful in
the case that either the numerator or the divisor or both is
negative, since there is no universally accepted definition of 
how to perform such integer divisions.  In SQL, the decision 
was to follow Fortran's MOD and C's fmod functions to define the 
remainder (see ANSI INCITS H2 paper H2-2003-390, available on 
request from Fred Zemke, Oracle).  These precedents both define 
that the sign of the remainder is the same
as the sign of the numerator.  Thus
numerator = divisor * quotient + remainder
where sign(remainder) = sign(numerator)
and abs(remainder) < abs(numerator)
completely specifies the integer quotient and remainder.
This happens to agree with all four of your examples, so it
is presumably what you meant.  This is corroborated by the
discussion in 6.2.6 op:numeric-mod.

- Steve B.

STATUS:  Fixed.

    

SECTION 6.2: functions and operators on numerics

last sentence before 6.2.1: "The number of digits of precision 
returned...is implementation-dependent."  I think this statement
is only necessary when the return type is xs:decimal.
If the return type is xs:integer, then there are obviously
0 places precision after the decimal point, and the precision 
above is limited by the implementation-defined maximum and 
minimum values for xs:integer.  If the return type is 
xs:float or xs:double, you can say that the operation,
and hence the precision of the result, is dictated by the 
IEEE floating point standard.  As for xs:decimal, the precision
ought to be implementation-defined rather than 
implementation-dependent, which leaves the user completely in the 
dark about the behavior.

- Steve B.

STATUS:  Fixed.

    

SECTION 2.4: fn:base-uri

It says: "If the base-uri property for $arg is empty, the base-uri
of that node's parent is returned."  As written, this is not
recursive, meaning that you would never consult the base-uri
of the grandparent of a node.  I think this is not what you mean.
If you mean this to work recursively up the tree until it finds
a node with a base-uri, or reaches the root, you should say so.


Perhaps replace the sentence with: 
If the base-uri property for $arg is empty, the base-uri
of that node's parent is returned by the equivalent of fn:base-uri($arg/..)." 

- Steve B.

STATUS: Fixed.

    

SECTION 1.4: type hierarchy

The diagram shows xs:positiveInteger as a subtype of 
xs:nonNegativeInteger, but the tabular presentation does not list
this relationship.

The tabular representation shows int, short, byte as same level subtype of long, but they are subtypes down the hierarchy (also the unsigned types).

There may be other inconsistencies in the tabular form.


- Steve B.

STATUS:  Fixed.

    

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1]. We do 
not expect a response for this purely editorial comment.

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-009 Editorial

Misspelled: "follwed" in 1.6.
Spurious full stop at beginning of sentence ".If" in 9.4.13.

STATUS:  Fixed.

    

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-004 fn:escape-uri and percent (7.4.10)

Given the potential confusion regarding whether PERCENT SIGN "%" is
escaped or not (we read that it is never escaped by fn:escape-uri),
we suggest some explanatory comments be added so that the user will
be confident that this an intentional variation from the cited RFCs.
For instance, you might add that if a user wishes to convert a file
name (which may contain a "%") to a URI then he or she must first
manually escape any "%" by replacing it with "%25".

Also, since you are aligning with XLink, a reference to XLink would be
appropriate

    

The WGs agreed on 2004-09-28 that the semantics of fn:escape-uri should be aligned with XLink 
and the semantics were correct as written and that this comment could be closed with appropriate 
editorial changes.

Acknowledged.

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-003 fn:data algorithm description (2.3)

        fn:data($arg as item()*) as xdt:anyAtomicType*

        Summary: fn:data takes a sequence of items and returns a sequence
        of atomic values.

        The result of fn:data is the sequence of atomic values produced 
by
        applying the following rules to each item in $arg:
           *  If the item is an atomic value, it is returned.
           *  If the item is a node, fn:data() returns the typed value of
            the node as defined by the accessor function dm:typed-value
            in Section 6.6 typed-value AccessorDM.

The use of "returns" in the item description is confusing (since it
implies the end of the function), and we're not sure what happens when
the item is a node with a list type itself, since a sequence cannot
contain other sequences.  Perhaps it would be less confusing if the
process were described as first creating an empty sequence, and then
appending values to it for each input item as appropriate, and finally
returning the composed sequence.

STATUS:  The fn:data algorihm has been rewritten with these comments in mind.

    

Dear Colleagues,

This comment pertains to the 25 December 2003 internal WD of XQuery 1.0
and XPath 2.0 Functions and Operators, as provided to our WG [1].

[1] 
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Feb/0000.html

Xan Gregg, on behalf of the XML Schema Working Group
----------------------------------------------------

XSCH-FO-001 Tabular type hierarchy errors (1.4)

The tabular form of the type hierarchy contains the following errors:
- positiveInteger is omitted
- short and byte have the wrong parent type
- unsignedInt, unsignedShort, and unsignedByte have the wrong parent
type

STATUS:  Fixed.

    

The XQuery version should shortened to:

declare function eg:duration-equal($arg1 as xs:duration, $arg2 as 
xs:duration)
     as xs:boolean
{
   return ( ( cast as xdt:yearMonthDuration($arg1) eq
              cast as xdt:yearMonthDuration($arg2) )
            and
            ( cast as xdt:dayTimeDuration($arg1) eq
              cast as xdt:dayTimeDuration($arg2) )
}

Till Westmann 

STATUS:  This is a really minor change.  It does not correct an error but
merely rewrites the function a bit differently.  I don't think we need to
make this change.  Ashok Malhotra

    

There no error code for "Error retrieving resource".

Till Westmann

    

The WGs agreed to add this error message.
this form.  Joint WGs telcon, May 25, 2004.

1) The seventh paragraph talks about the "greatest" item.

2) All examples except for the first one are syntactically incorrect, 
as the parentheses are missing.

Till Westmann

This is a typo.  Will fix.

All examples except for the first one are syntactically incorrect, as 
the parentheses are missing.

Till Westmann

STATUS:  Fixed.

    

No reference for detailed type semantics given.

Till Westmann

STATUS: The WGs decided to accept the wording suggested by Michael Rys in
http://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0092.html.
No type semantics are required.	

    

No reference for detailed type semantics given.

Till Westmann	

STATUS:  In the joint WG meeting on 8-23-2004 we decided to move this issue
to the formal semantics cluster.  When the semantics for this function are
defined in the FS document we will add a pointer from the F&O to that
definition.

    

There is a "TT" in the second dateTime of the second example.

Till Westmann

STATUS:  Fixed.

    

In the summary table durations are multiplied and divided by decimals, 
in the detailed descriptions they are multiplied and divided by 
doubles.

1) The summary table and the detailed descriptions should be consistent.

2) As the value space of the duration types is decimal, decimals should 
be used.

Till Westmann

    

The WGs decided to change the type of the arguments from double
to decimal for the reasons stated.

The example

fn:get-hours-from-time(fn:adjust-time-to-timezone(xs:time("01:23:00+05: 
00"), xdt:dayTimeDuration("PT0H")))

should return fn:get-hours-from-time(xs:time("20:23:00Z")) = 20.

Till Westmann

STATUS:  Fixed.

    

The example

fn:get-minutes-from-dateTime(xs:dateTime("1999-05-31T13:30:00+05:30"))

should return 30.

Till Westmann

STATUS: Fixed.

    

1) There is a cross-reference to DM section 5.1. But this section does 
not contain a description of the document-uri accessor.

2) As fn:document-uri returns () if the document-uri property is a 
relative URI, the last sentence should be:
If the fn:document-uri($arg) does not return the empty sequence, then 
the following expression always holds.

Till Westmann

STATUS:  Point 1 is incorrect.  Made language change as suggested in 2.

    

The text and the figure are not aligned concerning xs:IDREFS, 
xs:IDREFS, xs:NMTOKENS, xs:ENTITIES and user-defined list and union 
types.

Till Westmann

STATUS:  Wording clarified.

    

In F&O 17.10 Casting to date and time types

The functions convertYearToString, convertTo2CharString, 
convertSecondsToString, convertTZtoString
- use fn:length instead of fn:string-length
- $intLength is cast as a string, then compared to an integer

--Sarah

STATUS:  Fixed.

    

The error message "invalid timezone value" that is raised by the adjust-*
functions does not have a corresponding error number and is not listed in
Appendix D.

 
Thanks,
Priscilla Walmsley

Editorial.  Fixed.  AM 2004-03-04

    

The description for the fn:id function reads:

"Each string in $arg is parsed as if it were of type xs:IDREFS, that is,
$arg is treated as a space-separated sequence of tokens, each acting as an
IDREF."

But $arg itself is not space-separated, and the phrase "sequence of tokens"
should really be "list of tokens" if you are talking about a space-separated
string.  I think it would be more correct/clear to say:

"Each string in $arg is parsed as if it were of type xs:IDREFS, that is,
each string in $arg is a space-separated list of IDREF tokens."


Thanks,
Priscilla Walmsley

    

Appendix D lists a number of errors that are never mentioned elsewhere in
the draft. 

They include FONS0002, FORG0006, FOTY0001, FOTY0013, FOTY0014, FODC0002, and
FODC0003.

I would recommend either removing these or adding an explanation of when
they occur.

Thanks,
Priscilla Walmsley

Fixed.

In the description of deep-equal, F&O says:

"The two nodes ... may also differ in their parent, their base URI, and
their IDs. "

Is this referring to node identity?  If so, I think it should say "node
identities" instead of "IDs", which might be confused with attributes of
type xs:ID.


Thanks,
Priscilla Walmsley

STATUS:  Overtaken by events.  Wording changed based on other decisions.

    

Appendix B has some old signatures and describes some old behaviors.  For
example, it says that the contains, starts-with, ends-with,
substring-before, substring-after and normalize-space functions can return
the empty sequence, which is no longer true. The appendix has outdated
signatures of these functions as well.

Thanks,
Priscilla Walmsley

STATUS:  Editorial.  AM to check and fix.

    

The raising of errors has an inconsistent appearance across the family of 
documents. This issue is purely editorial in nature.

XQuery 1.0, in Section 2.1.1, Static Context, states:

        If analysis of an expression relies on some component of the 
static context that has
        not been assigned a value, a static error is raised.[err:XP0001]

Appendix F, Summary of Error Conditions, states:

        err:XP0001

            It is a static error if analysis of an expression relies on 
some component of the static context that has not been assigned a value.

F&O, in Section 7.5.1, fn:contains, states:

        If the specified collation is unsuitable for this function an 
error ·may· be raised
        [collation unsuitable for this function].

Section D, Error Summary (Non-Normative), states:

        err:FOCH0004, collation unsuitable for this function

Finally, Serialization, in Section 2, Serializing Arbitrary Data Models, 
states:

        It is a serialization error if the value cannot be cast to 
xs:string.


I suggest that clauses of this nature be made more consistent in their 
style. I prefer the style used by XQuery 1.0.

                                                        -- Andrew

--------------------
Andrew Eisenberg
IBM
5 Technology Park Drive
Westford, MA  01886

andrew.eisenberg@us.ibm.com
Phone: 978-399-5158    Fax: 978-399-5117

STATUS:  We agreed to follow the XQuery/XPath style.  Fixed.

    

In the examples section for fn:number the values for $item1 and $item2 are missing. 
		14.1.4.1 Examples
*	fn:number($item1/quantity) returns 5.
*	fn:number($item2) returns NaN.

STATUS: The definitions appear at the start of the section. No action
is needed.
    

Suppose $e is bound to an element that looks like this:

         <e xsi:type="xs:integer">1 2 3 4 5</e>

Now consider the following expression:

         data($e)

Is an implementation required to return the values in the original order? 
Would an implementation be conformant if it returned 5 4 3 2 1? I believe 
our answer is "yes", but I can't find where our specs say so clearly.

Jonathan

STATUS: Agreed to add note to datamodel document to clarify on 1/19 in
Tampa.

    

14 Functions and Operators on Nodes
    14.1 Functions and Operators on Nodes
        14.1.1 fn:name
        14.1.2 fn:local-name
        14.1.3 fn:namespace-uri
        14.1.4 fn:number
        14.1.5 fn:lang
        14.1.6 op:is-same-node
        14.1.7 op:node-before
        14.1.8 op:node-after
        14.1.9 fn:root


This is too-nested. Or do we miss section 14.2 ?


Thanks,

Dimitre Novatchev.

STATUS:  Fixed. Thanks! 


    

The description of mod uses expressions the expression
(a idiv b)*b+(a mod b) 
that is (one assumes) XPath/Xquery, (although other cases of explict
xpath examples the operators have op: or fn: syntax so this probably
ought to be
op:numeric-multiply(op:numeric-integer-divide(a,b) ,b)...


however it also uses the phrase

  the result obeys (a/b)*b+(a mod b) = a. Division is truncating division,
  analogous to integer division, not [IEEE 754-1985] rounding division.

The expression there is a valid Xpath, but not the desired expression:-)
I assume that the second sentence is intended to give a local definition
of "/" but
a) I think some other syntax should be used in
   preference to "/" to avoid confusion, and
b) I don't think "analogous to integer division" is clear enough as a
   specification.

If a and b are positive I assume you want something 
equivalent to the Xpath floor(a div b)*b+(a mod b) = a
Although It's not clear whether mod should be _defined_ that way in
terms of the Xpath floor and div (which may affect certain edge cases).


David

STATUS:  Editorial.  Fixed.
    

http://www.w3.org/TR/xpath-functions/#func-escape-uri

The rules tell me that '#' is not escaped if $escape-reserved is true.
However, in the first example the result contains %23 instead of #.

Is there any special reason to use "http://www.example.com/..." for
the first example and "http://example.com/..." for the second?
I recommend to use the same input parameter for both examples.

Regards,
Oliver Becker

STATUS:  Editorial.  Fixed.

    

I wrote:

> Last comment: the sentence (at the beginning of this section)
> 
> "The effect of the function is to replace any special character in the string 
> by an escape sequence of the form %HH, where HH... is the hexadecimal 
> representation of the octets used to represent the character in UTF-8."
> 
> could be interpreted as to generate one % and then the hex representations
> of all UTF-8 octets. 

If the example at the end would contain at least one non-ASCII character then
the desired behaviour would also be much clearer.

Oliver Becker

STATUS:  Editorial.  Fixed.

    

The wording in 7.4.10 fn:escape-uri of the Functions and Operators WD
seems to suggest that the percent sign '%' is not escaped if $escape-reserved
is false. (Because '%' is neither a reserved character in RFC2396 nor in
RFC2732.)

If I'd be picky then the wording

"If $escape-reserved is false, the behavior differs in that characters referred 
to in [RFC 2396] and [RFC 2732] as reserved characters, together with the NUMBER 
SIGN '#' character, (See [Uniform Resource Identifiers (URI): Generic Syntax]) 
are not escaped. These characters are ..."

tells me that *only* these reserved characters will be not escaped.

The rules would be easier to understand if it could be rephrased along
the lines:
- Regardless of $escape-reserved the following characters will be escaped: ..
- If and only if $escape-reserved is false then additionally the following 
  characters will be escaped: ...
  
Last comment: the sentence (at the beginning of this section)

"The effect of the function is to replace any special character in the string by 
an escape sequence of the form %HH, where HH... is the hexadecimal 
representation of the octets used to represent the character in UTF-8."

could be interpreted as to generate one % and then the hex representations
of all UTF-8 octets. Especially the "HH..." seems to suggest this 
interpretation. Perhaps the phrase "an escape sequence of %HH parts" or
something like that makes the intention clearer and unambiguous.

Regards,
Oliver Becker

STATUS:  Editorial.  Fixed.

    

The example given will not produce the stated results if $item1, $item2
and $item3 are not three unique nodes.

$item1, $item2 and $item3 must be defined or at least it must be said that
they are three unique nodes.


Dimitre Novatchev.

STATUS:  Editorial.  No change needed.


    

The examples are:

fn:deep-equal($item1, $item2) returns false.

fn:deep-equal($item1, $item1) returns true .

fn:deep-equal(($item1, $item2), 2.3E0) returns false.

It is not clear why the result of the first example must be false as the
variables $item1 and $item2 are not defined.


Dimitre Novatchev

STATUS:  Editorial.  No change needed.

    

There are two issues with this function:

 1. The description is confusing: 
    �This function takes a sequence, or more typically, an expression, 
     that evaluates to a sequence, as input .�
    
Is �an expression, that evaluates to a sequence� a separate datatype in
Xpath/Xquery 2.0? This phrase is not necessary, confusing and has to be
removed. All other functions "take an expression" that evaluates to the
necessary argument types -- we know this and don't need to be told this
just for one specific function.


 2. There isn't a meningful example to demonstrates the usefulness of this
function. The explanation given does not tell the reader when and why to
use the function:

"Query optimizers may be able to do a better job if the order of the
output sequence is not specified. For example, if you want to retrieve all
the prices from a purchase order, and if there is an index on prices, it
may be possible to compute an unordered result more efficiently."

This tells the reader why he/she may receive unordered sequence as result,
not why and when he/she should use fn:unordered() to provide an unordered
sequence to other functions.


Dimitre Novatchev.

    

There are two issues here.

Issue 1.
========

The "Summary" says:

"Summary: Returns the sequence that results from removing from $arg all
but one of a set of values that are eq to one other. Values that cannot be
compared, i.e. the eq operator is not defined for their types, are
considered to be distinct."

According to this summary, the example given:

"15.1.9.1 Examples
fn:distinct-values(1, 2.0, 3, 2) might return (1, 3, 2.0)."

is wrong.

If we remove from (1, 2.0, 3, 2) all but one of a set of values that are
eq to one other -- e.g. remove 2, then what we'll get will be:

     (1, 2.0, 3)

The Summary misses the very important fact that the unique values are
returned in any order -- so it is not just removing...

This fact is mentioned just at the end of the section:


"Which value of a set of values that compare equal is returned, along with
its original type annotation, is �implementation dependent�. Note that
xs:dateTime, xs:date or xs:time values can compare equal even if their
timezones are different. The order in which the sequence of values is
returned is �implementation dependent�."

The reading and understanding of this paragraph is made difficult, because
the meaning of the second sentence has nothing to do with the meaning of
the first and third sentence.

The second sentence has to be moved to its proper paragraph.


Issue 2.
=======

The example 

"15.1.9.1 Examples
fn:distinct-values(1, 2.0, 3, 2) might return (1, 3, 2.0)."

is also incorrect, because three arguments and not just one are passed to
the function. In this case the function should throw an error.

A correct example might be:

fn:distinct-values( (1, 2.0, 3, 2) ) might return (1, 3, 2.0).


Dimitre Novatchev

STATUS:  Editorial.  Fixed.

    

DN-FO-01: 15. Functions and operations on sequences

Class: Editorial

At present Chapter 15 has the following naming and structure:


15 Functions and Operators on Sequences
    15.1 Functions and Operators on Sequences
        15.1.1 fn:zero-or-one
        15.1.2 fn:one-or-more
        15.1.3 fn:exactly-one
        15.1.4 fn:boolean
        15.1.5 op:concatenate
        15.1.6 fn:index-of
        15.1.7 fn:empty
        15.1.8 fn:exists
        15.1.9 fn:distinct-values
        15.1.10 fn:insert-before
        15.1.11 fn:remove
        15.1.12 fn:reverse
        15.1.13 fn:subsequence
        15.1.14 fn:unordered
    15.2 Equals, Union, Intersection and Except
        15.2.1 fn:deep-equal
        15.2.2 op:union
        15.2.3 op:intersect
        15.2.4 op:except
    15.3 Aggregate Functions
        15.3.1 fn:count
        15.3.2 fn:avg
        15.3.3 fn:max
        15.3.4 fn:min
        15.3.5 fn:sum
    15.4 Functions and Operators that Generate Sequences
        15.4.1 op:to
        15.4.2 fn:id
        15.4.3 fn:idref
        15.4.4 fn:doc
        15.4.5 fn:collection


Section 15.1 has exactly the same title as the whole chapter. Because
the other sections in the chapter have other titles, the reader may
wonder whether only the functions in section 1.1 really operate on
sequences.

Solution: Change the title of section 15.1 to something more specific.


Dimitre Novatchev.

P.S. This was essentially my comment from 23 June 2003. 
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0180.html

Nothing has changed in the new version of the WD... Hope this time there
would be at least a response.

STATUS: Editorial.  Fixed.

    

Several places in F&O, references are made to the special value "+INF".
According to XML Schema, this is not a valid lexical form for float/double
values - only "INF" is allowed.  I think these references should be removed.

Thanks,
Priscilla

STATUS:  Editorial.  Fixed.

    

In section 7.6.1.1, it says:

"In string mode, the metacharacter . matches any character whatsoever. In
multiline mode, the metacharacter . matches any character except a newline
(#x0A) character. Suppose the input contains "hello" and "world" on two
lines. This will not be matched by the regular expression "hello.*world" in
multiline mode. "

This appears to be old text, since string mode is no longer defined, and
multiline mode no longer has anything to do with the metacharacter ".".  

Thanks,
Priscilla

STATUS: Editorial. Fixed.

    

The description of op:numeric-mod says:

"If $arg2 is zero, then an error is raised [division by zero]."

Shouldn't this say, 

If $arg2 is zero, and the operands are of type xs:integer or xs:decimal,
then an error is raised [division by zero]."

Because, as it says later, if they are float or double, it returns NaN
rather than raising an error.

Or is that sentence intended to be with the previous paragraph, which
appears to cover only the case where the operands are integer/decimal?  If
that's the case, maybe the sentence should be moved up to that paragraph.


Thanks,
Priscilla

STATUS:  Editorial.  Fixed.

    

It isn't clear why body of the Xquery implementation of 
eg:distinct-nodes-stable
does not just use the simple Xpath given on the line above rather than a 
for let where construct,

The current construct uses "isnot" which has been dropped from the
current draft of xquery/xpath.


David

STATUS:  Decided no change was needed.

    

C.4 is missing an XSLT implementation.

C.5 has an Xpath (rather than XSLT) implementation but I think it should
have a full xsl:function implementation.

I would expect to see this appendix becoming available as machine
readable versions (in some common namespace such as exslt) and it would
be easier to specify what should be implemented if all te hfunctions had
full declarations rather than just xpath fragments.


David

STATUS:  Mike Kay supplied the missing functions.  Added.


    

The informal description has a couple of instances of 
"then returns false." 
which would probably read better as "then the function returns false"
as otherwise there doesn't appear to be a subject.

 
> If $lang is the empty sequence it is interpreted as the zero-length string.

This should presumably be $testlang as there is no parameter called
$lang in the function signature.

> (The character "-" is HYPHEN-MINUS, %x002D) 

The syntax %x002D isn't used elsewhere, I suspect that #x002D is meant,
as that is used in other places to denote a character by hex unicode
value.

The relevent attribute is unambiguously specified by an Xpath expression
but the equality test used is described by a rather contorted (and
perhaps under specified) prose description. It would be clearer if
function was specified in its entirety by an Xpath expression,

something like

fn:upper-case(fn:replace((ancestor-or-self::*/@xml:lang)[last()],'-.*',''))
=
fn:upper-case($testlang)


using an explict expression (specified as using unicode codepoint
collation) such as the above would make it clearer what is meant by the
current wording "ignoring case".

If "ignoring case" means first uppercase then compare then

dotless i would compare equal to i
and
ess-zed would compare equal to SS

however if "ignoring case" means first lowercase then compare
then both of the above two comparisons would compare non-equal.

I don't think the current wording defines which of these (or other
possible interpretations) should be used.


Alternatively (and perhaps preferably) "ignoring case" should be
replaced by an explict reference to
1.3 Caseless Matching
in the Unicode case mapping appendix (TR 21).


Note however that the current normative reference to Tr21 in F&O is to
http://www.unicode.org/unicode/reports/tr21/ 
however that page just says

  Superseded Technical Report

  UAX#21: Case Mappings has been incorporated into the Unicode Standard
  Version 4.0, and is thus now superseded. The last version of that
  document before it was superseded can be found at
  http://www.unicode.org/reports/tr21/tr21-5.html

So it might be better to make the normative reference be Unicode 4, with
a non-normative reference to tr21-5, for the benefit of those of us
without a unicode 4 book.


David

STATUS:  Editorial. Fixed.

    

Section 5.1 states:

The form of that function for a type /pref:TYPE/ is:

This was initially unclear to me. I pronounce "pref" like the first 
syllable of "preference". I suggest this section should either spell out 
the entire word prefix or just use "pre" (the first syllable of the word 
prefix) instead. "pref" just doesn't say "prefix" to me. :-(

--
Elliotte Rusty Harold

STATUS: Agreed to fix in Tampa.  Close.