The
February 11, 2005
working draft includes a number of changes made in
response to comments both received during the Last Call period that ended
on Feb. 15, 2004. The working group is continuing to process these
comments, and additional changes are expected.

Most issues are classified as either substantive, meaning the editor
believes technical changes to the document are required to address them,
or editorial, meaning that the issue is one of specification clarity
not technical correctness.

An issue transitions through several states. Issues tracking begins
when an issue is raised. After discussion,
the Working Group may have decided.
how to resolve the issue. This decision is
announced. and hopefully
acknowledged. by the commenter(s).
For the most part, once an issue is decided, it is considered
closed.

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.

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.

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.

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.

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..

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).

"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?

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.

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.

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.

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

In F&O 14.1.3, namespace-uri was changed to return an xs:anyURI instead
of an xs:string. The sentence "If $arg is the empty sequence, the
zero-length string is returned" is no longer valid. There may be other
occurrences of this in the document where xs:string was changed to
xs:anyURI.
In similar cases (11.2.3) the signature is xs:anyURI?.
So either:
fn:namespace-uri() as xs:anyURI?
fn:namespace-uri($arg as node()?) as xs:anyURI?
If $arg is the empty sequence, the empty sequence returned.
or:
fn:namespace-uri() as xs:anyURI
fn:namespace-uri($arg as node()?) as xs:anyURI
If $arg is the empty sequence, xs:anyURI("") is returned.
Mike Kay in http://lists.w3.org/Archives/Public/public-qt-comments/2004Sep/0044.html
recommends we treat the empty string as a valid URI and return it.

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*
....

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).

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 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

(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

(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

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

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.

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.

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.

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.

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.

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

Section 5 Constructor Functions
Technical
Constructor function signatures should have the following signature:
pref:TYPE($arg as xdt:anyAtomicType?) as pref:TYPE?
See also comment MS-XQ-LC1-121
(http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0529.htm
l)

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/

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/

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/

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]

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).

(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

(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

(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

(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

(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

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

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

(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

(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

(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

(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

(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

(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

(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

(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:
"Postponed for later discussion (related DM issues, clustered by Norm)"

(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

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.

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.

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

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

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.

[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

[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.

qt-2004Feb0973-01: [F&O] IBM-FO-105: \0 should be prohibitied as a back reference in regular expressions

[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

[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

[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

[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.

qt-2004Feb0940-01: ORA-FO-253-Q: Suggest changing fn:distinct-values signature back to fn:distinct-values($arg as item()*) as item()*

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.

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.

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.

qt-2004Feb0904-01: ORA-FO-250-B: Inconsistent types for $position in various functions.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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, "#" ) )

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.

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.

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.

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.

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.

qt-2004Feb0726-01: ORA-FO-184-B: fn:subtract-dateTimes-yielding-yearMonthDuration function name is too long

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.

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.

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.

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

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.

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.

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.

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?

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.

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.

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"?

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.

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

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

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 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 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 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.

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

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

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

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

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

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.

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

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

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

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

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.

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:

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.

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

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

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.

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.

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.

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.

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

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

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

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

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

> 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.

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].

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 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.

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 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
.

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-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-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.

qt-2004Feb0917-01: ORA-FO-378-E: Please move "Namespaces and prefixes" prior to any use of these namespaces

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!

qt-2004Feb0912-01: ORA-FO-337-E: Unclear wording: "the collation may fail", "the system may reject it"

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 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.

qt-2004Feb0902-01: ORA-FO-248-C: need to clarify the behavior of union, intersect and except

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.

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.

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 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.

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.

qt-2004Feb0883-01: ORA-FO-170-E: use narrower indentations to get the whole type hierarchy on normal width paper

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.

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.

qt-2004Feb0881-01: ORA-FO-167-E: "numeric" as a return type is not properly specified

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.

qt-2004Feb0733-01: ORA-FO-193-B: incorrect use of "maximum value" and "minimum value"

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.

qt-2004Feb0719-01: ORA-FO-177-B: need to specify how to compute the remainder when dividing negative numbers

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.

qt-2004Feb0716-01: ORA-FO-173-B: nonrecursive definition of something that probably should be recursive

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.

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.

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

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.

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

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.

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

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.

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.

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.