Functions and Operators: Comments on Last Call Document

Version $Id: FandO-lastcall-comments.xml, v1.0 2003/09/03 23:25:30

This document summarizes the comments on the XPath Functions and Operators Last Call document dated May 2, 2003. Comments received via both public amd member-only mailing lists, up until May 25, 2003, are recorded in this version of the document.

Material reproduced from comments has been marked up, and obvious typos have been corrected. Postings and documents which raise several substantively distinct points have been silently divided among several comments. To consult the original postings, see the sources listed for each comment.

Commentators are requested to review the entries for the comments they have made, and to check to make sure we have correctly understood and paraphrased their comment.

Not all postings to the comments mailing list have resulted in entries in this list. For example, postings which ask for clarification and do not result in any errata, are not necessarily included in this list.

The status of each issue is recorded in the table. The status may be:

Open

A new issue, not discussed yet.

In progress

The WG is currently discussing the issue. The issue may or may not be classified. See the classification field for further information.

Resolved

The issue has been classified and a resolution agreed upon by the WG. A note to the commentator may still be pending.

Closed

The issue is resolved. New or changed text has been approved and has been or will be added to the document. No further work is required.

LC1-0001. fn:id() and fn:idref() work only on trees rooted in document nodes.

Description

The fn:id() and fn:idref() functions work only on trees rooted in document nodes. It is possible to define them to work on arbitrary trees but probably not worth the effort.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Apr/0045.html

Discussion

Discussed and approved on the F&O telcon on 2003-04-24. See member-only minutes

Resolution

Approved by the XML Query WG on 2003-05-07; by the XSL WG on 2003-05-01. Text added 2003-05-07.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0002. We need an abs function.

Description

We need an abs function. Certain expressions are difficult to write without one.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Apr/0044.html

Discussion

Discussed and approved on the F&O telcon on 2003-04-24. See member-only minutes::http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0032.html

Resolution

Approved by the XML Query WG on 2003-05-07; by the XSL WG on 2003-05-01. Function added 2003-05-09.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0003. Should we allow comparison between hexBinary and base64Binary values?

Description

Should we allow comparison between hexBinary and base64Binary values? They have the same value space.

From the discussion on the 2003-04-24 telcon.

Discussion

Two possibilities: Just allow comparison, or require casting of one to the other to change the data type annotation. Mike Kay argued for the require-casting approach. Agreement to require the use of casting for comparisons. Values of the two types are not mutually comparable, but such values can be cast from one type to the other (which, we recognize, doesn't change the value at all, but only changes the type annotation).

Discussed and approved on the F&O telcon on 2003-04-24. See member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0032.html

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0004. Should we allow casting from hexBinary to base64Binary?

Description

Should we allow casting from hexBinary to base64Binary?

From discussion See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Apr/0045.html

Discussion

See FO-LC1-0003 above.

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0005. Should we allow casting from binary types to xs:boolean?

Description

Should we allow casting from hexBinary and base64Binary to xs:boolean?

Discussion

We agree that such casting is not useful and that we will remove it from the casting table and chapter.

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0182.html

LC1-0006. Change base-uri argument to fn:resolve-uri to xs:string.

Description

The base-uri argument to the fn:resolve-uri() function is xs:anyURI. It should be xs:string.

Discussion

The fn:resolve-uri() function will be fixed to take xs:string instead of xs:anyURI. The default type used to specify collation arguments is also xs:string and not xs:anyURI. In section 16.7, fn:default-collation, currently returns an "xs:anyURI?" and will now return "xs:string?".

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0007. What does fn:document-uri accept?

Description

fn:document-uri() is defined to accept any kind of node. In the datamodel it is defined on document nodes only. This needs to be resolved. See member-only message http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0038.html

Discussion

There are two approaches being discussed: The current document specifies that the empty sequence is returned if the argument is not a document node; Norm suggested that the function could "walk up the tree" to the document node and behave as though that document node were passed. Andrew and Paul argued that the F&O specification does now what was proposed and accepted by the groups. Paul said that the Data Model document could be changed by changing the semantic of the corresponding accessor, dm:document-uri(), which is invoked by the definition of fn:document-uri(). After some discussion, it seems that a small rewording in F&O (replace "does not have a document-uri property" to "is not a document node") will give us the desired result.

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0008. Change function signatures to node() and item().

Description

Change function signatures to node() and item()to match production in Xquery/XPath. See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0033.html

Discussion

We will do a global edit to change "as node" and "as item" to "as node()" and "as item()", respectively.

Resolution

Approved by the F&0 taskforce on 5/13/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0009. fn:default-collation() should return a xs:string.

Description

fn:default-collation() still returns xs:anyURI, though collations elsewhere are always represented by a xs:string. Member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0033.html

Discussion

The return type of fn:default-collation() will be changed to xs:string.

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0010. Change error condition if collation argument is invalid.

Description

What error should be raised in $collationLiteral is not a valid xs:anyURI? Discussion at F&O meeting on 2003-05-13.

Discussion

fn:default-collation() and other functions specify that an error is raised when a collation URI does not satisfy the lexical rules for anyURI, which is not really deterministic. Debate revealed that there are no complete rules for exactly what the lexical space of xs:anyURI is.

Resolution

Therefore, in the many places where it appears, the paragraph (or its equivalent) that says "If $collationLiteral is not in the lexical space of xs:anyURI, an error is raised ("Invalid collationURI")", will be replaced by a sentence saying that the collationLiteral references an invalid collation. Approved by the F&0 taskforce on 5/13/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0011. Why is the second argument of op:divide-dayTimeDuration and op:divide-yearMonthDuration an xs:decimal rather than an xs:double?

Description

Why is the second argument of op:divide-dayTimeDuration and op:divide-yearMonthDuration an xs:decimal rather than an xs:double? See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0033.html

Discussion

Because untyped data is interpreted as xs:double (when numbers are needed and implied), xs:double makes more sense than xs:decimal. This implies checking for overflow, etc. if _INF or -INF or NaN is provided. Mike Kay, after checking the XPath document, said that the operator promotion/mapping rules require some editorial attention.

We would have liked to change the type of the second argument op:divide-dayTimeDuration() and op:divide-yearMonthDuration(), and of the corresponding multiply functions, in from xs:decimal to xs:double. This change implies adding error invocations for multiplication/division by infinities and NaNs. This change also requires a change to the operator mapping table in the XQuery document. However, because of Mike Kay's issue (see preceding paragraph), we agreed to defer this comment until Mike produces a proposal.

Member-only proposal from Mike Kay: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0067.html

Resolution

The WGs approved the changes recommended. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0030.html

LC1-0012. fn:last() and fn:position() are documented as returning "xs:integer?". Should that be "xs:integer"?

Description

fn:last() and fn:position() are documented as returning "xs:integer?". Should that be "xs:integer"? See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Apr/0033.html

Discussion

Change the signature of these two functions to replace "xs:integer?" with "xs:integer". Replace the second sentence of each function's description with a sentence like "If the context item is undefined, then an error is raised ("Undefined context item")."

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0013. Names for the arguments to functions should be consistent.

Description

The names chosen for function parameters show no consistency. Sometimes we see srcval1 and srcval2, sometimes operand1 and operand2, sometimes parameter1 and parameter2. It would improve the aesthetics of the document if this were tidied up. See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0005.html

Discussion

This is left to the editors, who said that they will work on making the change (from various non-semantic argument names to names formulated as "argn") in their spare time. This is not important enough to justify delaying publication of a final document.

Resolution

Approved by the F&0 taskforce on 5/13/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0014. Should we reconsider the component extraction functions for the date/time datatypes?

Description

The comment suggests that we don't need many different functions, but could instead have a single function with an argument that specifies what component is to be extracted. See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0001.html

Discussion

Paul Cotton has already responded that the reason is to ensure that we have well-defined return data types instead of large union types. Andrew suggested that another reason is to avoid having to check the spelling of such an argument to ensure it's one of the permitted values.

Resolution

No change to documents.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0184.html

LC1-0015. The XSLT example function definitions all use the xsl:result syntax. The May XSLT draft does not have xsl:result.

Description

The XSLT example function definitions all use the xsl:result syntax from the previous draft. The May XSLT draft does not have xsl:result. See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0023.html

Discussion

Mike Kay will fix the problem either by revising the examples to use the current XSLT syntax instead of the previous syntax. The examples will be fixed by correcting the XSLT syntax used.

Resolution

Approved by the F&0 taskforce on 5/13/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0016. fn:root(): change the second signature to accept and return values of type "node()?" ; add examples.

Description

fn:root(): change the second signature (with an argument) to accept and return values of type "node()?" instead of type "node"; add examples of the function's use. See: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0008.html

Discussion

We agrred to change the second signature (with an argument) to accept and return values of type "node()?" instead of type "node". Add additional examples of fn:root() (including the example in the provided reference). There is no reason to change the first signature to return "node()?". Mike Kay will provide XSLT examples.

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0017. Refer to XPath as well as XQuery documents.

Description

All mentions of "XQuery" should really refer to both the XPath document and the XQuery document. See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0052.html

Resolution

Approved by the F&0 taskforce on 5/13/2003.

Response

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0027.html

LC1-0018. fn:deep-equal() is not defined usefully, and there are bugs in its definition.

Description

fn:deep-equal() is not defined usefully, and there are bugs in its definition. See thread: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0053.html

Discussion

Mike Kay says that this function is not sufficiently useful and well-defined to be retained in the document. Others said that it is frequently used, but the response was that the uses tend to be focused solely on the specific implementations (e.g., XSLT implementations) used by each user.

Resolution

We will fix the specific bugs identified in the referenced message. (1)In the various code fragments defining the semantics of the function, replace "returns false" with "returns fn:false()" (multiple places). (2)The code defining the semantics of the function must be rewritten to move the "and fn:compare(...)" component into the "then" branch and just return the result of fn:compare() instead of returning fn:false(). (3)In another code fragment, "empty" should be "fn:empty" for consistency. (4)We will do nothing about the treatment of top-level comment nodes versus other comment nodes, because we have no better solution.

Response

See messages in the thread: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0053.html

LC1-0019. Number to string conversion.

Description

Number to string conversion currently specifies that the canonical representation will be used, but that often violates the user's expectations that integral values shouldn't have visible exponents, that scientific notation is poorly understood by many See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0011.html

Discussion

Although we didn't reach an agreement, we are leaning towards using integer representation for integral values of type integer or decimal, decimal representation for values of type decimal (using canonical representation) and for values of types float and real with certain characteristics (e.g., between 10**-6 and 10**3), and scientific representation for values of types float and real without those certain characteristics. The details of those "certain characteristics" must be spelled out in a formal proposal.

Resolution

The WGs discussed this on 9/15/2003 and agreed to accept the proposal in member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0021.html with minor modifications. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Oct/0000.html

LC1-0020. Clarify initial input sequence.

Description

The description in XSLT 2.3 and the associated material in F&O 15.4.6 somehow never seems, to me at least, to get to the point and to clearly state what the initial input sequence is. See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0087.html

Discussion

There was extensive discussion of the input sequence and fn:input() in the XPath taskforce meeting on 5/14/2003 and it was decided to remove the function as we now have external variables and the input sequence can be assigned to an external variable.

Resolution

Remove fn:input(). Approved by the XQuery WG on 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0009.html.

LC1-0021. Format decimal proposal.

Description

Mike Kay reported that he initially drafted a proposal for a simplified version of XSLT's format-number() function, but he then realized that it could be further simplified. He intends to supply a proposal to put this simplified function into F&O, but there's the problem of providing the definition of the format itself; XSLT uses the xsl:format-decimal (?) element, and Andrew suggested that our function might allow an element analogous to the XSLT element as an additional parameter to the function. Mike thought that might be too hard for some users to swallow, so he's working on devising some sort of string notation. See member-only message: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0053.html

Member-only proposal from Mike Kay: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0069.html

Resolution

The WGs discussed this and decided that no action was necessary for this version. This should be added to the list of requirements for future versions. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0031.html

LC1-0022. When would fn:sum() return the empty sequence?

Description

When would fn:sum() return the empty sequence? See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0117.html

Discussion

We concluded that the return type specifying "?" is obsolete and is left over from the days before we made the (controversial) decision to return 0 (zero) when the argument is the empty sequence. We will change the return type of fn:sum() to remove the "?".

Resolution

We will change the return type of fn:sum() to remove the "?". In addition, we will (editorially) move the last rule of the description (dealing with NaN values) to immediately precede the rule dealing with empty sequences.

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0183.html

LC1-0023. Semantics of fn:insert-before().

Description

The rec currently says:

"The value returned by the function consists of all items of $target whose index is less than or equal to N, followed by all items of $inserts, followed by the remaining elements of $target, in that sequence."

Shouldn't that say just "less than N" rather than "less than or equal to N"? It seems the way it is worded, it should be named insert-after.

Also, it starts talking about "N" without introducing it in any way. I think this could be addressed by saying "... inserted at the position N ..." (i.e. adding the "N") in the first paragraph.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0118.html

Resolution

We agreed that the change from "less than or equal to" to "less than" is appropriate. We also agreed to change the second paragraph (dealing with normalizing the position numbers) and the fourth paragraph (dealing with empty sequences) will be placed into a note.

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0186.html

LC1-0024. Derivation of the two totally ordered subtypes of xs:duration.

Description

(1)The definitions of derived duration types should not have the prefix included as part of the definition (the definition takes the namespace in a different manner). (2)The pattern should not have linebreaks and other whitespace (that makes it a different pattern than intended). (3)The sentence "In this [XML Schema Part 1: Structures] fragment, the value of attributeFormDefault is unqualified." appears before each simple type definition. What does this mean?

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0121.html

Resolution

(1)The prefix xst: will be removed from the definition. (2)The pattern will be accompanied by a note to explain that the linebreaks and other whitespace is not part of the pattern but it displayed only to make the pattern readable in the specification. (3)We will remove the erroneous sentence.

Approved by the F&0 taskforce on 5/13/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0185.html

LC1-0025. Comments on fn:data() and fn:base-uri().

Description

Comments on fn:data() and fn:base-uri(). See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0122.html

Discussion

The referenced message contained 2 comments, one on fn:data() and one on fn:base-uri(). Ashok responded to the author that both were fixed as suggested. Michael Rys questioned the response dealing with fn_base-uri(). Norm said that the current F&O wording here is very close to the corresponding wording in Data Model; Norm already has an action item to address the text in both of the documents.

A clear improvement here is to remove the last sentence of the first paragraph ("The base-uri property for all other node types is the empty sequence."). But a better solution, as suggested during the discussion, would be to change the text so that it keeps only the reference to the Data Model specification of dm:base-uri (as expressed in the first sentence of the first paragraph), then convert everything else (suitably edited) to a non-normative note, deleting the last sentence of the first paragraph.

Resolution

We agreed to change the text so that it keeps only the reference to the Data Model specification of dm:base-uri (as expressed in the first sentence of the first paragraph), then convert everything else (suitably edited) to a non-normative note, deleting the last sentence of the first paragraph. In addition, we agreed to modify the introductory text in section 2, "Accessors", to read "The [Data Model reference] describes accessors and defines their semantics." Finally, on the last row of the table, "Node" should be "node".

Approved by the F&0 taskforce on 5/13/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0139.html

LC1-0026. local-name or local-part? Section 10.2, 14.1.2

Description

Should we use "local-name" or "local-part" in function namesd and semantic descriptions.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0130.html http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0132.html http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0133.html

Resolution

We agreed to use the phrases "namespace URI" and "local name" consistently in our documents, but to put a statement somewhere (section 1.6, "Notations") in the F&O spec that says: This document uses the phrase "namespace URI" to identify the same concept identified in [Namespaces] as "namespace name", and the phrase "local name" to identify the same concept identified in [Namespaces] as "local part". One change required is in the table at the start of section 10.2, "Functions related to QNames", replace "local part" with "local name" and in 10.2.1, "op:QName-equal", replace "local-name parts" with "local names". We also agreed not to change the name of the functions fn:get-local-name-from-QName() and fn:local-name because of the need for compatibility with the Infoset and XPath 1.0.

Approved by the F&0 taskforce on 5/13/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0188.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0190.html

LC1-0027. Change the name of the function in 10.2.3 to get-namespace-uri-from-QName.

Description

Change the name of the function in 10.2.3 to get-namespace-uri-from-QName.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0134.html

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0189.html

LC1-0028. Change the name of the function in 10.2.5 to get-in-scope-namespace-prefixes

Description

Change the name of the function in 10.2.5 to get-in-scope-namespace-prefixes

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0135.html

Resolution

Approved by the F&0 taskforce on 5/13/2003. Approved by the XQuery WG 5/28/2003. Approved by the XSL WG 6/05/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0187.html

LC1-0029. fn:idref semantics

Description

In the description of the idref function, the rec says:

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

Shouldn't that say something like "...lexically of a type that is a list of xs:ID"? Something that is lexically of type xs:ID would never be a space-separated list.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0119.html

Resolution

Ashok has already modified the wording in section 15.4.3, "fn:idref", to address the comment. We agreed that Ashok's rewording resolves the comment.

Approved by the F&0 taskforce on 5/13/2003.

Response

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0140.html

LC1-0030. fn:doc

Description

Commentator is unhappy with the change from fn:document() to fn:doc().

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0152.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0154.html

Resolution

Mike Kay has responded to the author with an explanation of why the function changed names and what the semantics really are. However, there is a fairly long thread associated with the first referenced message, so we decided to leave this comment pending for now.

The thread has died down so we decided to close the issue. If folks are really unhappy this may come up at the next last call again.

Response

See thread starting with: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0152.html

LC1-0031. fn:trace

Description

Commentator is unhappy with the semnatics of the fn:trace() function. He says "fn:trace() should be specified so that the output is added to the output tree in the same way as xsl:message would do."

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0153.html

Resolution

Mike Kay has communicated privately with the author of the comment, but we agreed to let the discussion continue for now.

Response

See thread starting with: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0153.html

Final response: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0117.html

LC1-0032. fn:remove wording.

Description

The F&O last call draft description of fn:remove (15.1.13) contains the phrase "no action is taken". This makes no sense. Functions never take actions, they only return values. I assume you mean to say "the function returns the value of $target". I suggest changing the description accordingly.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Apr/0179.html

Resolution

Ashok Malhotra agreed to fix this editorially.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0282.html

LC1-0033. node equality: do we need fn:node-equal()?

Description

op:node-equal() tests for identity instead of equality. fn:deep-equal() implements one definition of node-equality. This thread discusses other possible definitions of node equality and asks whether we need a function to implement one such definition.

See the thread starting: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0171.html

Discussion

Both Michael Rys and Michael Kay have argued on the thread that there are several possible definitions of node equality. There is no universal agreement on a definition and an additional function is not necessary.

Resolution

Response

See the thread starting: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0171.html

Final response: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0118.html

LC1-0034. Resolving Relative References to Absolute Form

Description

In Appendix C of that RFC, "Examples of Resolving Relative URI References", Section C.2, "Abnormal Examples", states explicitly:

An empty reference refers to the start of the current document.

<> = (current document)

Both of these appear to be in conflict with the last paragraph of F&O section 11.1 (before the Note), which states:

If the $relativeURI is the zero-length string, returns the value of the base-uri property from the static context in the first form and $base in the second form.

Section 2.1.1 of "XML Path Language (XPath) 2.0" does not provide for the current document's URI in the static context, only an environment-specified base URI.

There appear to be two alternatives:

1) Add text to section 11.1 stating that the URI resolution algorithm to be used differs from that in RFC 2396 in the case of a zero-length string $relativeURI, and that the base URI is the result instead of the current document's URI.

2) Add the current document URI, when available, to the static context and return it instead of the base URI if $relativeURI is the zero-length string.

In either case, additional text highlighting the zero-length relative URI string case should be added to sections 7.3, 15.4.4, and 15.4.5, which each mention resolution of relative URIs with respect to base URIs.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0209.html

Response

Michael Kay: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0221.html

LC1-0035. Casting QName to string

Description

This is a last call comment derived from implementation experience.

In the most recent draft, we introduced the capability to cast a QName to a string, using the in-scope namespaces from the static context to map the URI to a prefix.

To implement this, the processor needs to have available at run-time the full set of namespace declarations from the static context. In principle this is acceptable, there are other situations where this is also needed, especially in XSLT. However, there is a big problem in this case: the processor cannot always detect statically that the value will be a QName. If the static type can only be inferred as (say) item() or node(), then the processor must copy the namespace context into the run-time environment just in case the value (after atomization) turns out to have a dynamic type of QName. This is especially painful for XSLT processors that produce compiled code.

This is a heavy price to pay, and contravenes the principle that infrequently used facilities should not impose a performance cost on paths that are executed much more frequently.

I propose that we should revert to the previous situation:

* conversion of a QName to a string should be done using a special-purpose function: resolve-QName() with a single argument.

* casting of QName to string should be an error.

The use of the resolve-QName() function can always be detected statically, so the copying of the namespace context needs to be done only in a situation where the information is actually needed.

At first sight this is burdensome for the user, it means they cannot do something like

<xsl:value-of select="$param"/>

and have it work in the case where $param is a QName. However, the casting of QNames to strings needs special care anyway, because there is no guarantee that the relevant namespace is declared in the static context.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0229.html and member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0069.html

Resolution

The WGs discussed this on 9/18/2003 and decided to accept the recommendation and disallow casting xs:QName to xs:string. On further discussion it was decided not to provide a function to do such casting. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html and member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0072.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0187.html

LC1-0036. Is a query allowed in the URI argument to fn:doc()?

Description

What is allowed in the URI argument to doc() function? The spec states it cannot contain a fragment identifier. But can this URI include what the URI spec calls a query, i.e. something following a question mark, where the something is typically a list of name=value pairs, separated by ampersands. Here is an example:

fn:doc("www.example.com/name?last=SMITH&first=JOHN")

See member-only note: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0075.html

Response

Michael Kay responded, saying that the a query is allowed as the F&O dos not disallow it. See member-only note: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0077.html

LC1-0037. Semantics of fn:avg.

Description

Points out some editorial problems wirh fn:avg(0 as well as the semantic issue:

sum(()) div count(()) => 0.0E0 div 0 => NaN

avg(()) => ()

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0243.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0332.html

Resolution

This was discussed at the joint meeting of the WGs on 9/15/2003 and the semantics of the aggregate functions were overhauled. New wording was subsequently approved. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html and the joint WGs meeting on 10/01/2003 See member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0011.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0015.html

LC1-0038. Omission from fn:replace

Description

In F&O section 7.5.3, fn:replace(), para 6: after

"A literal $ symbol must be written as \$."

add the sentence

"A literal \ symbol must be written as \\.".

We agreed this, but although it is implicit in the description of one of the error conditions, it is not stated explicitly.

I think someone has already noted that in the penultimate paragraph of this section, "not immediately preceded by a "/"" should read "not immediately preceded by a "\"".

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0031.html

Resolution

Fixed! Editorial.

Response

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0032.html

LC1-0039. fn:type() proposal

Description

"My proposal was to return the type names of the actual type of the item and its supertypes in a sequence, as QNames, not strings. My feeling is that this gives the right amount of information to do most of the useful things you'd want to do with types, such as testing whether two nodes have the same type or annotating a node with its type.

"We don't argue that we should stop people having access to element names because we don't want to support access to element declarations, so I don't see why we should wait until the language can give us access to a type definition in order to provide a facility to work out an element's type."

See member-only threads: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0054.html

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0064.html

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0068.html

Resolution

At the F&O telcon on 5/29/03 we decided that the feature suggested seems to be a Vnext feature and that this note needed no further action at this time.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0115.html

LC1-0040. Back references in regexn.

Description

It would be very handy to have a back reference mechanism in the regexen spec use by XSLT etc. Much more succinct code could be written.

code = "foo = 'bar'"

# also works when " is used as attribute value delimiter

code =~ /([^\s=]+)(\s*)(=)(\s*)(['"])([^\5]+)(\5)/

(1..7).each do |i|

print i.to_s+': '

p eval('$'+i.to_s)

end

brings

ruby backref.rb

1: "foo"

2: " "

3: "="

4: " "

5: "'"

6: "bar"

7: "'"

A concrete Use Case: Marking up XML code listings.

XSLT: (slightly outdated): http://www.pinkjuice.com/howto/vimxml/xslt/tinydbk2xhtml/markup_xml.xslt2

Sample output: http://www.pinkjuice.com/howto/vimxml/intro.xml (at the bottom)

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0288.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0307.html

Resolution

At the June 12 telcon the F&O taskforce decided that the functionality requested was complex and decided not to add it to V1. Also, we follow the XML Schema regular expression syntax and the functionality requested in not included there.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0120.html

LC1-0041. Some of the functions in the F&O are unnecessary.

Description

"I wasn't saying that all these functions I listed should be dropped, just that if we want to reduce the implementation burden by limiting the number of functions then we need to prioritise the functions that we include. Our first priority should be functions that users cannot write themselves. Next in line are those functions that are very hard for users to write themselves and functions that users cannot write efficiently.

"I don't understand your point about static type reduction. Could you give me an example where zero-or-one() is useful? There doesn't seem to be an example in the use case document."

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0066.html

Resolution

At the F&O telcon on 5/29/03 we decided that this note needed no further action.

Response

See member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0010.html

LC1-0042. Default collation for contains(), starts-with(), ends-with(), substring-before(), substring-after()

Description

The current rules specify that the collation for the two-argument forms of the fn:contains(), fn:starts-with(), and fn:ends-with() is the default collation from the static context, just as it is for all other string operations.

I think there is a good case for saying that the default in these cases should be Unicode codepoint collation.

These functions are often used for parsing strings representing structured values such as filenames or document reference numbers. They are not designed for use, and are not really suitable for use, with natural language text. For both backwards compatibility and usability reasons, as well as performance, I think it makes much more sense for the simple form of these functions to use Unicode codepoint comparison. The user who wants to use the default collation can always use the three-argument form of the function.

See member-only notes: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0071.html and http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0230.html

Discussion

Member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003May/0073.html

Discussed at joint XSL/XML Query meeting on 7/16/2003. No decision. See item J7 in member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html

Resolution

This was discussed and approved by the WGs. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html. See also FO-LC1-0102.

Response

Member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Oct/0003.html

LC1-0043. Semantics of fn:normalize-space.

Description

I don't think it is clear what happens if a single non-space whitespace character is encountered. I assume that it is intended that a single non-space whitespace character will be replaced by a space character. If so, I suggest that that needs to be stated more clearly.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0326.html

Resolution

This was discussed at the F&O telcon on 5/29/03 and we agreed that Andre was correct and decided to change the wording to say "replacing sequences of one or more than one whitespace character with a single space, #x20" after checking with the XML 1.0 spec.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0330.html

LC1-0044. fn:trace ordering should be "implementation dependent" not "implementation defined".

Description

Section 4 of the F&O last call draft states that the ordering of output from invocations of the fn:trace() function is implementation defined.

Generally, this ordering (and whether the function is invoked at all) will depend on query optimizations. For an implementator to specify this order would mean that all optimizations and the exact circumstances in which they are applied would have to be specified in detail. To me, this seems too much burden on the implementor for a negligable benefit to the user.

I suggest that the output ordering be implementation dependent instead.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0178.html

Resolution

We discussed this on 6/26/2003 and agreed to the suggested change.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0139.html

LC1-0045. fn:reverse missing.

Description

I think F&O is lacking function for reversing sequence order. Something like this would be useful:

fn:reverse($sourceSeq as item*) as item*

It can be written as recursive function of course, but if there are functions like fn:exist in F&O, function like above could be added for clarity and possibilily of high optimization.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0329.html

Resolution

Agreed to add as an illustrative function on the 7/31/2003 telcon.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0000.html

LC1-0046. Why do the types passed to fn:distinct-values need to have a total order?

Description

Why do the types in the argument passed to fn:distinct-values need to have a total order?

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0???.html

Resolution

Ashok Malhotra replied that this had been corrected in response to a previous comment.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0331.html

LC1-0047. AVTs inside regexn.

Description

In a user forum of an XSLT processor, it was asked if allowing AVTs inside regexen should be disallowed because coders could forget to escape curly braces that aren't meant to delimit AVTs, eg quantifier delimiters.

I just wanted to say that I think that you should continue to allow AVTs inside regexen. This offers flexibility, and coders can be expected to remember escaping [see note].

Note:

See http://www.w3.org/TR/xslt20/#function-regex-group. Because the regex attribute is an attribute value template, curly braces within the regular expression must be doubled. For example, to match a sequence of one to five characters followed by whitespace, write regex=".{{1,5}}\s".'

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0287.html

Resolution

At the Jun 12, 2003 telcon Michael Kay pointed out that this was an XSLT item and need not be taken up by the F&O taskforce. See member-only minutes http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0041.html

Response

None required.

LC1-0048. fn:deep-equals redux

Description

The definition of deep-equal means that two empty document nodes always compare false:

deep-equal(document { () }, document { () }) => false()

because "... if neither node has element children, then the result is true only if the other node also has simple content ..." and document nodes never have simple content.

Also, I think the whole definition for the node case could be reduced significantly by negating it and making some minor rewrites.

And finally, because namespace nodes cannot be selected or constructed alone by any XQuery expression, and because the recursive deep-equal definition for element skips namespace nodes, why are they included in the list ("If the two nodes are ... namespace nodes...")?

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0335.html

Resolution

We discussed this on 6/26/2003 and agreed to make the suggested changes.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0141.html

LC1-0049. Make fn:resolve-QName and fn:get-namespace-uri-for-prefix signatures consistent.

Description

The resolve-QName and get-namespace-uri-for-prefix functions have inconsistent signatures for no good reason:

resolve-QName(xs:string, element) as xs:QName

get-namespace-uri-for-prefix(element, xs:string) as xs:string

Both should have the element argument in the same position.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0001.html

Resolution

We agreed to make the suggested change on 6/26.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0131.html

LC1-0050. Use different font to indicate return types that vary with the type of the input.

Description

The document says "In some cases, the dynamic type returned by a function depends on the type(s) of its argument(s). These special functions are indicated by using bold italics for the return type."

Problem: Bold italics is not as clear to read as it needs to be for anything of this significance, especially if the font is Courier which often has no good bold rendering.

Recommendation: Use a combination of a different font, bold and underline.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0064.html

Resolution

The editors have not been able to find a suitable typographical style but will continue to investigate. At the F&O taskforce meeting on 9/11 we agreed to continue the investigation but close the issue. This was approved by the joint meeting of the WGs on 9/15/2003. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0028.html

LC1-0051. Remove the namespace URI for the op: prefix

Description

In Section 1.7 Namespace Prefix it provides a URI to the op: prefix.

Problem: URI bound to op: prefix will require implementations to respect the namespace (e.g. ensure users do not also use this namespace). If the op: prefix is only to describe the functionality of the operators, it is useless overhead to assign it a namespace.

Proposed resolution: Remove the namespace URI and use a sentence to indicate that the prefix is only used for definitional purposes (see for example the fs prefix in the Formal semantics).

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0066.html

Resolution

We discussed this on 7/18/2003 and agreed to remove the namespace associated with the op: prefix.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0140.html

LC1-0052. Static type of fn:trace

Description

Problem: In order to be a function that has no impact on the semantics of the query, the fn:trace function needs to preserve the static type of the input. The current specification does not express this.

Proposed solution: Mark the result type using the special indication and define the static semantics in the formal semantics document.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0070.html

Resolution

We agreed to this change on 7/18/2003.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0132.html

LC1-0053. Type derivation figure issues

Description

The figure that represents the type hierarchy has the following problems:

1. It misses the namespace URI or prefixes

2. It confuses people w.r.t. derivation by lists

3. It is missing the node types

Proposed solution: Replace it with a version of the type hierarchy figure in member-only message http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0096.html

In addition, T.V. Raman would like a text description of the figure. He also would like us to retain the indented type hierarchies that precede some of the major sections.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0071.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0127.html as well as http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0073.html which asks that the indented lists of types be removed.

Discussion

We agree to replace existing figure with the new, improved figure. The WAI comments still need to be addressed.

Resolution

Figure has been replaced with type hierarchy diagram as supplied by Michael Rys. We have added a text table that reproduces the information contained in the table at the request of the WAI folks. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0137.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0089.html

LC1-0054. Timezone preservation considered problematic

Description

In section 1.4 xs:dateTime, xs:date and xs:time values, the specification requires to preserve timezones (presence or absence and actual value).

This requirement makes the 3 atomic types into 3 tuple-types that have some severe implementation consequences (for example, the full, physical representation of the types are not binary comparable anymore).

It also contradicts most date/time types available in other languages where the following design has been the accepted way of dealing with timezoned and local values:

1. Define a local and UTC-based datatype.

2. Normalize the UTC-based datatype to Z-time.

3. Provide formatting options to transform the UTC-based type to a specific timezone.

4. Provide transforms to move a local type instance to UTC-based and vice-versa.

This design would be done in a manner similar to the refactoring of the xs:duration datatype.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0072.html See also note from Xan Gregg: http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0257.html

Resolution

At the joint meeting on 9/15/2003 the WGs decided not to accept the recommendation in the above message. The XML Schema WG has accepted, in principle, to add timezones into the value space for date and time types. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0063.html

LC1-0055. Bad example with pattern on non-string type

Description

Section 6.2 Operators on Numeric Values uses the following example:

As another example, a user may define height as a derived type of xs:integer with a minimum value of 20 and a maximum value of 100. He may then derive oddHeight using a pattern to restrict the value to odd integers.

Do not use an example with a pattern on a non-string type. Pattern restrict the lexical space which leads to problems when there is no 1-to-1 correspondence (as pointed out in other parts of the spec). Providing an example that does use a pattern in this way, may lead to the believe that this is a safe and accepted use.

Proposed resolution: Remove or change this example.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0074.html

Discussion

Resolution

We discussed this on 7/18/2003 and agreed to change the example not to use a pattern.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0138.html

LC1-0056. Precision implementation-defined or implementation-dependent.

Description

Why does section 6.2 define the number of digits of precision as implementation-dependent and not -defined? I assume that an implementation will want to document the precision.

Proposed resolution: Make it implementation-defined.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0077.html

Discussion

We discussed this on 7/18/2003 and decided not to make the change.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0133.html

LC1-0057. Too many functions!

Description

Remove the following functions:

1. fn:context-item() -- This is a trivial synonym for ".". No-one is likely to use it.

2. fn:current-date() and fn:current-time() -- These can be trivially derived from fn:current-dateTime().

3. fn:deep-equal() -- This is semantically complex and unlikely to meet everyone's needs for comparing equality. Users can write their own version to match their own needs. The use of deep-equal() in distinct-values() can be replaced by making distinct-values a (higher-order) operator instead of a function: EXPR "with" "distinct" EXPR ("," EXPR )*

4. fn:distinct-nodes() -- This is likely to be needed rarely and can be trivially written as $x/.

5. fn:empty() -- This is trivial syntactic sugar for "count($x)=0", or "not($x)". The name is also misleading, since other XML specifications use the word "empty" to mean "having no children": users will make the mistake of thinking that empty(E) is true if E is an element with no children.

6. fn:ends-with() -- The effect of this function can be readily achieved using the fn:matches() function with a regular expression.

7. fn:exists() -- This is trivial syntactic sugar for "count($x)!=0", or "boolean($x)".

8. fn:index-of() -- This is a rarely-needed function, and index-of($s, $v) can be readily rewritten as "for $i in 1 to count($s) return if ($s[$i] eq $v) then $i else ()"

9. fn:insert-before() -- The most common requirement is to insert at the start or the end, which can be achieved using the "," operator. The rare requirement to insert in the middle can be achieved using " ($target[position() lt $position], $inserts, $target[position() ge $position])"

10. fn:item-at() -- The effect of this function can be easily achieved using a numeric predicate.

11. fn:node-kind() -- It is easy to test the kind of a node using "instance of" (or "type switch" in XQuery)

12. fn:remove() The effect of this function can be readily achieved by writing "$target[position() ne $n]"

13. fn:sequence-node-identical() -- This function is very rarely required; if it is ever needed, it can be written as " every $i in 1 to max(count($arg1), count($arg2)) satisfies ($arg1[$i] is $arg2[$i])"

14. fn:string-pad() -- This function can be readily written as "string-join(for $i in (1 to $padCount) return $padString, "")"

15. fn:subsequence()

Some pushback on removing some of the functions. Also, some comments about whether functions should be removed or made optional.

See thread starting: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0082.html

Support for removing fn:empty():

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0186.html

Support for removing fn:exists():

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0187.html

Support for removing fn:context-item():

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0213.html

Resolution

This was discussed by the F&O taskforce and they recommended the following actions. These were approved by the WGs on 9/15/2003. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Remove fn:context-item.

Remove fn:distinct-nodes. Add as an example function.

Remove fn:node-kind.

Remove fn:sequence-node-identical.

Remove fn:string-pad(). Add to appendix D as an example function.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0006.htmly

LC1-0058. Functions on dates, times and durations

Description

This proposal has several components:

Create functions to map durations to a pair of numbers (months, seconds) then do all arithmetic and comparisons on this pair. Remove the ability to extract the components of a duration. This manipulation can be done using regular expressions on the string value.

Eliminate the functions that add a date/time to a duration or that form a duration as the difference between two date/times, replacing them with the ability to determine the interval in seconds between the start of the specified date/time and 2000-01-01T00:00:00Z.

Many functions on dates and times are provided in three variants, one for each of the three types Date, Time, and DateTime. In the case of numerics, we deal with this problem by defining an abstract superclass "numeric". It is not clear why we have not adopted the same solution for operations on the calendar data types.

We have a range of functions to extract components of dates and times. The main use case for these is to allow formatting of the date and time. Yet there is no function in the core library to format a date and time.

Propose that the format-date/time/dateTime functions be moved from XSLT into the core, and that we rely on these for applications that need to extract the components.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0087.html and member-only messages: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0073.html http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jun/0075.html

Discussion

Discussed at the joint WG meeting on 9/15/2003 and a detailed proposal was requested. This was provided in http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0114.html.

Resolution

In the F&O taskforce meeting on 9/25/2003 it was decided to postpone consideration of this far-reaching proposal to the next round of publication. This was approved by the joint WGs on 10/01/2003. See member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0010.html.

Response

See http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0007.html.

LC1-0059. Remove fn:trace()

Description

Software AG does not believe that there is any good reason to include fn:trace() in the core function library.

We already have diagnostic features in our product that are much more sophisticated and usable than the proposed fn:trace() function. We do not have a sensible way of implementing fn:trace() in our product architecture, and we believe that as a result of query optimization, the output is likely to be unintelligible to most users.

We see no need for diagnostic capabilities to be standardised. This should be an area that is left entirely to implementors to add value.

We recommend that the fn:trace() function should be dropped, or at least marked as optional.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0091.html

Resolution

We discussed this on 7/18/2003 and decided not to make the change.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0134.html

LC1-0060. Aggregate functions

Description

The polymorphic nature of the aggregation functions, such as min/max/avg, has not been thought through carefully enough.

It is important that these functions should be capable of a streamed implementation. This means that if the first 999 values in a sequence are untyped atomic, the choice of comparison or addition operator should not depend on the type of the 1000th item. (Note that "order by" in XQuery has this right: untyped atomic values are treated as strings, irrespective of the types of the other items in the sequence).

These functions (in particular sum) also have a problem in how they handle the empty sequence. Because an empty set of doubles is not dynamically distinguishable from an empty set of durations, sum() applied to the latter returns the double value 0.0e0, which is in conflict with static typing expectations. The only solution to this problem seems to be to stop overloading the sum() function to handle durations (as proposed in FO-LC1-0058).

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0092.html

Discussion

At the joint meeting on 9/15/2003 the WGs decided to accept the recommendations in principle but wanted a detailed proposal to look at and approve. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html. This was provided in member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0028.html .

Resolution

Approved at the joint WG meeting on 10/1/2003. See member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0011.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0005.html

LC1-0061. NaNs in avg, max, min, sum

Description

The specifications for fn:avg, fn:max, fn:min, and fn:sum don't say what all of these functions return if the argument is a sequence containing only NaNs.

Either the specification must define, that if after discarding these NaNs no other values remain (i.e. an empty sequence) then the empty sequence is returned. (Short "If $srcval contains exclusively NaN values then the empty sequence is returned.") Or the whole discarding rule is dropped (I noted already a compatibility problem for fn:sum), and the definitions have to be rephrased properly (e.g. for fn:min "... the item in $srcval whose value is not greater than the value of every other item ..."), thus, if a NaN value is in $srcval then the result is NaN.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0149.html

In a separate thread, Michael Kay says:

In Xpath 1.0, although the spec is far from explicit on the point, you can be pretty sure that sum() over a sequence that includes a NaN will return NaN.

It's not at all clear to me that the current 2.0 specification, which removes NaNs before doing the summation, is preferable. Why did we change it?

See member-only note: http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jun/0031.html

Discussion

Based on discussion a 7/24/2003 F&O telcon clarified the wording and replied to Oliver Becker.

Resolution

The WGs discussed this on 9/16/2003 and decided that, as part of a set of changes to the semantics of aggregate functions the recommended semantic would be supported. If the sequence passed to any of the aggregate functions contains one or more NaNs, NaN is returned. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0166.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0190.html

LC1-0062. zero-or-one, one-or-more, exactly-one

Description

The names describe properties and suggest that these functions return boolean result. However, this is not the case.

Another issue with these functions is that their main purpose seems to be in raising an error message if the property they name is not true for the parameter-sequence. Such functions seem strange and their necessity and potential usage must be explained in detail.

A third issue is that the description for all three functions contains the sentence: "The type of the result is the type of $srcval." This is clearly contradicted by the definitions of the functions -- item* is not the same as item?, item+ or item.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0181.html

Resolution

Agreed on the 7/31/2003 telcon to add explanatory text suggested by Phil Wadler.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0001.html

LC1-0063. fn:distinct-nodes

Description

This function is of little use because: "The order in which the distinct nodes are returned is implementation dependent". The programmer will not be able to find the answer to the following two questions:

1. Which nodes and in what order are exactly returned?

2. What should we do if we need to preserve order in the result?

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0188.html

Resolution

This was discussed on 9/15/2003 and it was decided to remove the function. An example function should be added to Appendix D to illustrate one semantic for such a function. Users can use this pattern to write functions that support the semantics they desire. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0045.html.

LC1-0064. fn:distinct-values

Description

1. This function is of little use because "he order of the values returned is implementation dependent". The programmer will not be able to find the answer to the following two questions:

- Which values and in what order are exactly returned?

- What should we do if we need to preserve order in the result?

2. The example is wrong: "fn:distinct-values(1, 2.0, 3, 2) returns (1, 3, 2.0)" Actually: fn:distinct-values(1, 2.0, 3, 2) might return (1, 3, 2.0) because the order in which the values are returned is implementation dependent.

See thread starting at: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0189.html

Discussion

Resolution

At the 7/24/2003 F&O agreed to add wording to clarify.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0167.html

LC1-0065. fn:unordered

Description

1. The description is completely confusing. It is not specified what the function returns and the definition is very imprecise: "This function takes a sequence or more typically, an expression, that evaluates to a sequence, and indicates that the result sequence may be returned in any order."

2. Is "an expression, that evaluates to a sequence" a separate datatype in Xpath/Xquery 2.0?

Suggested solution:

- Explain precisely what the function does, what it returns and why/when it might be useful.

- Consider removing this function from the document.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0193.html

Resolution

At the 7/24/2003 F&O telcon we agreed to add appropriate wording and close the issue.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0168.html

LC1-0066. fn:sequence-node-identical

Description

1. The name is misleading. The name suggests that the function will return a sequence of the corresponding nodes in two sequences, which (the nodes) are identical.

2. Incorrect definition: "Returns the empty sequence if one or both of its arguments is the empty sequence." This is not correct. If:

$seq1 = () and $seq2= (someItem)

a programmer would expect (what seems more intuitive) that:

sequence-node-identical($seq1, $seq2) = false

It is not clear why it is necessary to use three-valued logic with this function.

Suggested solution:

1. Correct the name to better reflect the semantics of the function.

2. Simplify the semantics by using two-valued logic.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0195.html

Resolution

The WGs discussed this on 9/18/2003 and decided to remove the function as it is rarely used. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html and member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0072.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0188.html

LC1-0067. fn:subtring-after

Description

The substring-after specification mentions "the first occurrence of a string that is equal to the value of $operand2". However, for some collations (e.g., those ignoring combining diacritical marks) there could be multiple substrings of $operand1 that start with the same character but have different lengths and that are all equal to $operand2. It is not clear which of these substrings is the "first" one. You should specify whether the shortest or the longest such substring should be used.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0212.html

Resolution

The WGs discussed this on 9/16/2003 and decided that this was related to the issue about collation units, FO-LC1-0111. If the description of the function is changed to use collation units then the situation described does not arise and the issue can be closed. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0189.html

LC1-0068. Collation arguments

Description

Are collation arguments restricted to literals? This was the status at one point and some feel it was changed to permit an expression. We discussed this on the document inspection on 6/24/2003 and did not reach a resolution. If collation arguments are restricted to literals we need to say this. If they are not, we need to globally change '$collationLiteral' to $collation.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0214.html

MRys says "Make the collation argument a literal". See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0346.html and response http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0051.html

MRys says "Make explicit collation URI support an optional feature or higher conformance level". See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0330.html.

Resolution

The WGs discussed this on 9/15/2003 and confirmed that collation arguments to functions do not need to be literals. All function parameters named $collationLiteral should be renamed. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0000.htmly

LC1-0069. More functions should allow an optional first argument

Description

Many more functions should allow zero or one values for the first argument. For example:

fn:collection( $srcval as xs:string) as node*

fn:escape-uri( $uri-part as string, $escape-reserved as xs:boolean) as xs:string

fn:resolve-uri( $relative as xs:string, $base as anyURI) as xs:string

fn:resolve-QName( $qname as xs:string, $element as element) as xs:QName

fn:root($srcval as node) as node

fn:string-to-codepoints($srcval as xs:string) as xs:integer*

escape-uri and resolve-uri have typos: missing 'xs' prefix (should be xs:string, xs:anyURI

fn:lang($testlang as xs:string) as xs:boolean

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0217.html

Resolution

Overtaken by events. The functions in question now allow the empty sequence as the first argument.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0059.html

LC1-0070. Signatures of subtract-dateTimes, etc. should allow the empty sequence.

Description

Signature of 9.7.1 fn:subtract-dateTimes-yielding-yearMonthDuration, 9.7.2 fn:subtract-dateTimes-yielding-dayTimeDuration, 9.7.3 op:subtract-dates and 9.7.4 op:subtract-times need to allow the empty sequnce as arguments and to return the empty sequence.

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0297.html

Resolution

The WGs agreed to the changes recommended. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0107.html

LC1-0071. fn:boolean

Description

Signature of fn:boolean should allow item() not item()*. No semantics are specified for a sequence input, merely for atomic values.

Align with EBV. EBV of untypedAtomic?

Align with "cast as boolean".

See: http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0299.html, and member-only notes http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jul/0007.html, http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0051.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0032.html

Resolution

fn:boolean should return effective boolean value. Semantics are different from "cast as boolean". See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0108.html

LC1-0072. fn:item-at

Description

Semantics should be the same as $x[$n]. Buxton says ""If the value of $posParam is ... equal to zero (0), then an error is raised ". This is inconsistent with the way the substring functions work". Mike Kay says "If we are to keep item-at($x, $n) then it should have the same behavior as $x[$n]. And if it has the same behavior, then we might as well drop it." http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0303.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0077.html

Resolution

The WGs discussed this and decided to remove fn:item-at. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0110.html

LC1-0073. Functions that return strings inconsistent

Description

Sometimes return () and sometimes "". See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0308.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0370.html and response http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0061.html

Resolution

This was discussed on 9/15/2003 and it was decided that string functions should interpret the empty sequence as the zero-length string. As a consequnce, none of the string functions now return the empty sequence. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0051.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0052.html

LC1-0074. Inconsistent arguments to string functions

Description

Sometimes take xs:double, (substring and subsequence) sometimes integer (insert, remove, pad). See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0310.html

Resolution

This was discussed by the WGs and it was decided that no change was necessary. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0109.html

LC1-0075. Semantics of fn:translate if passed empty sequence.

Description

Also backwards compatibility issue in XSL review. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0311.html and XSL Review.

Resolution

This was discussed by the WGs and it was decided that this change should be made. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0120.html

LC1-0076. fn:lang

Description

Should allow a node as argument. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0378.html. Response http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0066.html

An argument of "" should match all languages. Item [121] in I18N review http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed by the WGs and it was decided that no change was necessary as the function is not very useful. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

The WGs decided that a empty string argument should always return 'false' while I18N wanted it to always return 'true'.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0121.html

LC1-0077. fn:distinct-values

Description

Promotion of untypedAtomic. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0109.html and make incomparable distinct http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0105.html. and http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0107.html

Retain first occurrence. See thread DN-FO-09 http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0011.html.

Resolution

This was discussed by the WGs and it was decided that values of type xdt:untypedAtomic should be compared as xs:string and incomparable values should be treated as distinct. The WGs declined to make the requested change that the first occurrence of a set of values that compared equal be returned. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0122.html

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0123.html

LC1-0078. fn:match

Description

Multiline mode is confusing. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0088.html. Liam says behaviour different from Perl. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0090.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0091.html

See also Item [71] in http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html which says use the Perl term 'minimal' instead of 'reluctant' quantifier. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0032.html

Resolution

In response to a proposal by Michael Kay, (See member-only communication http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0064.html) it was decided to add an "s" flag to match Perl's single-line mode and add support for back references. This was approved by the joint WGs on 10/01/2003. See member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0011.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0031.html.

LC1-0079. fn:replace

Description

Should allow $pattern, $replacement to be empty sequences. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0317.html

What's the first match? See member-only thread http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0023.html

Resolution

Although it was decided to accept the suggestion to add back references to our regex support it was decided not to change the signature of fn:replace as suggested. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html and member-only minutes of the F&O telcon http://lists.w3.org/Archives/Member/w3c-query-operators/2003Oct/0023.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0081.html and member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Oct/0024.html

LC1-0080. fn:tokenize

Description

Problems with understanding example in which ".?" is used to tokenize a string into its constituent characters. See long thread starting http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0112.html

The sentence "If the supplied $pattern matches a zero length string... should be clarified, ... I think the natural interpretation of "matches" here is the interpretation of matches used in replace(), and in this case that is a greedy match as .? is greedy, so since it is the entire regexp it is equivalent to . and will match each character. While .? _could_ match an empty string, it doesn't here so the empty string should not be used as separator." Mike Kay responds "That's a good point. The intended meaning of the sentence was:

if (fn:matches("", $pattern))

See http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0126.html

Also, add example -- fn:tokenize("abba", "") returns ("a", "b", "b", "a")

See also member-only proposal by MHK http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0070.html

Resolution

This was discussed by the WGs and it was decided that a pattern that matches the empty string should raise an error. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0125.html

LC1-0081. Casting untypedAtomic for arithmetic and comparisons.

Description

Argues that it should be cast to other type with xs:double as default. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0326.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0042.html

See also member-only thread starting http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jul/0034.html

Resolution

This was discussed by the WGs and it was decided not to make the change as @price*2 would result in a type error if @price was untypedAtomic "3.14" because this cannot be cast as xs:integer. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0126.html

LC1-0082. fn:insert-before semantics

Description

Is a deep or shallow copy of $inserts inserted into $target? See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0331.html

Resolution

This was discussed by the WGs and it was decided to clarify the wording to indicate that $inserts itself, and not a copy, was inserted. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0131.html

LC1-0083. fn:unordered semantics

Description

Oracle would prefer this to be a directive rather than a function. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0332.html

Resolution

This was discussed by the WGs and it was decided not to make the change recommended as a function provides finer-grained control than a directive. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0132.html

LC1-0084. fn:collection semantics

Description

Should accept an empty sequence and return an empty sequence. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0341.html

Should return metadata as well as sequence of nodes. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0379.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0054.html

Comment [143] from the I18N WG questions semantics and utility of function. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html. In a private communication Jonathan Robie argued that there was no implementation independent usecase for the function and that it should be removed.

Resolution

This was discussed by the WGs and it was decided that no change was needed. fn:collection accepts the empty sequence and returns the empty sequence. An empty string is considered to be a relative-uri. On the metadata issue, there has been some support for additional functionality but the WGs decided not to include it in version 1 but consider it as a requirement for future versions. The issue about the utility and interoperability of this function is discussed in the member-only thread http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0114.html. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0134.html

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0135.html

LC1-0085. Inconsistent conversion rules for fn:avg and fn:max.

Description

The type conversion rules for fn:max, fn:min are inconsistent with the type conversion rules for fn:avg. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0343.html

Resolution

This was discussed by the WGs and it was decided to fold this issue into a larger issue about the semantics of aggregate functions -- FO-LC1-0060. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0136.html

LC1-0086. Base URI for collations?

Description

Do we need a base URI for collations in the static context? Currently relative collation URI references are resolved according to the base URI in the static context. We think that there may be cases where the general base URI will be different from the collation base URI. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0345.html.

Resolution

This was discussed by the WGs and it was decided not to add the functionality suggested. The user can put the base-uri for collations into a variable and use the variable to resolve relative-uris for collations. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0137.html

LC1-0087. String functions should treat () as "".

Description

fn:starts-with and most other string functions have an XPath 1.0 incompatibilty: () maps to "" in XPath 1.0 string functions. No good reason to be incompatible. Treat () as zero-length string and return xs:boolean instead of xs:boolean?. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0370.html. Support from MHK http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0061.html.

Resolution

This was discussed by the WGs and it was decided to fold this issue into a larger issue about the semantics of () and "" for string functions -- FO-LC1-0073. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0138.html

LC1-0088. Minimally conformant processors need not support negative years.

Description

Minimally conformant processors need not support negative years. See conformance note 9.1.1. Just as they do not need to support more than 4 digits. Both were introduced by Schema as extensions to ISO 8601 formats. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0354.html

Resolution

This was discussed by the WGs and it was decided that there was no reason to be gratuitously different from XML Schema in this regard. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0139.html

LC1-0089. Which version of Unicode?

Description

Which version of Unicode should we refer to and support? XML Schema WG comments that the specs should be consistent. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html

The I18N WG wants us to refer to Unicode 4.0 and change reference to case mapping to Annexure #15 of Unicode 4.0 and the normalization forms defined in Unicode 4.0. See also http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html

Paul Biron recommends adding a note. See member-only communication: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0048.html

Resolution

The WGs discussed this and decided that the F&O should refer to XML Standard for consistency. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0102.html.

LC1-0090. fn:normalize-unicode

Description

Normalization form W3C now "fully-normalized" MUST be supported. See XML Schema comments item [2.6] http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html and I18N WG comments item [62] http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html. They want the reference changed to Unicode 4.0 normalization forms.

Resolution

There is no algorithm defined for the 'fully-normalized' form and it is unclear how to achieve the 'fully-normalized' property without throwing away information in some cases. The WGs, therefore, declined this suggestion. Some felt that we should wait until the Character Model became a Recommendation before acting on this item. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0184.html

LC1-0091. fn:concat arguments

Description

Concat with zero rguments is not useful. Concat with one argument can be kept if extended to accept a sequence. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0369.html. Michael Kay disagrees http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0065.html. Also Jeni Tennison http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0043.html.

Resolution

This was discussed by the WGs and it was decided to remove the zero and one argument versions of fn:concat(). See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0171.html

LC1-0092. An unescape-uri function?.

Description

It would be useful (and symmetrical) to define fn:unescape-uri. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0372.html

Resolution

This was discussed by the WGs and it was decided that the function was not sufficiently useful to be included in the F&O document. If the originator wants to pursue this further he should provide usecases. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0173.html

LC1-0093. Remove fn:get-namespace-uri-for-prefix and fn:get-in-scope-namespaces

Description

These functions are providing namespace axis functionality that XQuery decided not to provide. We do not see a reason to provide them in function form either. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0016.html.

Michael Kay disagrees. "Without this functionality (these two functions and resolve-QName), it becomes completely impossible to manipulate QNames in schema-less documents. This functionality was provided after careful consideration as a replacement for the namespace axis. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0063.html.

Resolution

This was discussed by the WGs and there was insufficient support for removing the functions. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0174.html

LC1-0094. fn:resolve-uri

Description

1. $relative should have type xs:string? not xs:string, since it is not a "steering" parameter. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0017.html.

2. Allow node as second argument and get $base from it. Comment [113] in I18N WG comments. http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed by the WGs. The first point has been agreed to and implemented in response to an earlier comment. The WGs declined to make the change requested in the second point as there is a function, fn:namespace-uri, that can be used to get the base-uri for a node. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0177.html

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0178.html

LC1-0095. Make text in fn:name and fn:local-name XPath only.

Description

Make text re. namespace nodes in fn:name and fn:local-name a XPath only comment. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0024.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0028.html.

Resolution

The WGs decided to accept the suggestions and add appropriate notes to the functions in question. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0179.html

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0180.html

LC1-0096. fn:root.

Description

1. fn:root() should error if root node is not a document node. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0033.html. Michael Kay agrees http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0059.html.

2. Better static typing is needed for fn:root(). See See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0036.html.

Resolution

The WGs discussed this and decided to make no change to fn:root but, instead change the formal semantics to define / as "fn:root() treat as document()". See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0181.html

LC1-0097. Rename op:node-equal to op-node-identical

Description

op:node-equal should be renamed op:node-identical to avoid value semantics interpretation. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0037.html.

Resolution

The WGs discussed this and decided to change the name of op:node-equal to op:is-same-node. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0111.html

LC1-0098. Several function should require homogeneous atomic sequences.

Description

Homogeneous Atomic Sequences as argument to fn:sum, fn:avg, fn:min, fn:max, fn:distinct-values, and fn:index-of. See member-only thread starting http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0014.html.

Resolution

The WGs discussed this and decided to merge this with FO-LC1-0060 and the larger discussion of aggregate functions. Michael Kay withdrew his comment on fn:index-of(). See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only message http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0070.html

LC1-0099. Static type of fn:trace

Description

Wouldn't it be more convenient to have it return empty () instead of the input? I assume that in many cases, the corresponding information does not need to be used further, or if it is, it is already bound in a variable somewhere. See member-only note http://lists.w3.org/Archives/Member/w3c-query-editors/2003Jul/0055.html.

For the record, the corresponding type inference rule would be:

statEnv |- Expr : Type

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

statEnv |- fn:trace(Expr):Type

See member-only note http://lists.w3.org/Archives/Member/w3c-query-editors/2003Jul/0056.html.

Resolution

The WGs discussed this and decided not to make the change. The function needs to be used by both languages. This change would make it difficult to be used by XPath. The usecase can be achieved by supplying () as the first argument. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-query-editors/2003Sep/0114.html

LC1-0100. Should booleans be ordered?

Description

Should booleans be ordered? Do we need op:boolean-less-than, op:boolean-greater-than? Also why no op:and and op:or functions? See item [1.7] in http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html. and item [77] in http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

Michael Kay replies ... "XPath 1.0 defines an ordering on booleans and we thought it worth retaining for backwards compatibility. There are use cases, for example the sort specification:"

<xsl:sort select="age ge 18"/>

<xsl:sort select="surname"/>

will sort children before adults, and then by surname within each category. See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0011.html.

Resolution

The WGs discussed this and decided to add a note to explain the situation. See comments by Michael Kay above. Member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0182.html and

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0183.html

LC1-0101. Add note re. IANA URIs for collations.

Description

IANA is creating a registry for collations. Collations will be identified by URIs. XML Query functions should use these URIs to identify collations. Functions may also use opaque vendor-defined collations identified by URIs

Since the IANA registry is not available yet, and we do not have a timetable, the I18N WG suggests that the F&O should insert a note re. the above decision. Mark Davis suggested the following text in a private note: Note: Work is current progressing on an IANA registry for collations and an RFC specifying the interpretation of such URIs. If URIs from such a future IANA registry are used to specify a collation in XML Query, then the operation of such a collation must be in accordance with the specifications in the RFC.

The member-only minutes of the telcon are at: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Aug/0062.html.

Resolution

The WGs discussed this on 9/18/2003 and decided that we would add such a note when a there was a public statement or RFC to refer to. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

Member-only note: http://lists.w3.org/Archives/Member/w3c-query-operators/2003Sep/0071.html

LC1-0102. Two default collations?

Description

Since functions that test for equality and functions that do substring matching use different 'strengths' it may be desirable to create two default collations - one for equality testing and the other for substring matching.

Member-only minutes: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Aug/0062.html. See also responses to thread started by above.

Resolution

The WGs discussed this on 9/18/2003 and decided that the default collation for fn:contains, fn:subtring-before, fn:substring-after, fn:starts-with and fn:ends-with should be the Unicode codepoint collation. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

LC1-0103. Remove fn:upper/lower-case

Description

Item [2.7] from Schema WG comments: http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html.

Sections 7.4.12 and 7.4.13 define functions for case folding. Since case folding is not consistent across languages and locales, we have grave doubts about the wisdom of this inclusion, and some members of the WG would advise you to drop these functions, which are not and cannot be language- and culture-neutral.

There is precedent: the decision to drop case-folding of names from the design of XML resulted from the realization that every case-folding algorithm available, including the use of the Unicode case mapping tables, has an inherent cultural bias. The inclusion of culturally and linguistically biased functions does not contribute to achieving the goal of universal accessibility for the Web. Some members of the XML Schema WG believe your spec should not go forward with these functions in it.

If you retain these functions, you should at the very least warn users that

* Results may violate user expectations (in Quebec, for example, the standard uppercase equivalent of "é" is "É", while in metropolitan France it is more commonly "E"; only one of these is supported by the function as defined).

* Many characters of class Ll lack uppercase equivalents in the Unicode case mapping tables (we stopped counting at 150 or so); many characters of class Lu lack lowercase equivalents.

* The two functions are not inverses of each other, so that for a string S of upper-case characters, fn:upper-case(fn:lower-case(S)) is not guaranteed to return S, nor is fn:lower-case(fn:upper-case(S)) for a string S of lower-case characters. Latin small letter dotless i (as used in Turkish) is perhaps the most prominent lower-case letter which will not round-trip, as Latin capital letter i with dot above is the most prominent upper-case letter which will not round trip; there are others.

You may also wish to make the case mapping depend on the default or a user-specified collation.

Resolution

The WGs discussed this on 9/18/2003 and decided not to remove the two functions but add the cautionary notes suggested by the XML Schema WG. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0183.html

LC1-0104. fn:escape-uri

Description

Should use the algorithm from Character Model or the Linking Spec (same algorithm. Why is % escaped in some cases and not others? See item [2.8] in http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html.

Comments from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

[67] It is unclear what these functions are supposed to do with anyURIs/IRIs.

[68] It is unclear what the case of $escape-reserved == false is supposed to do. ... Please give us a better example, ... It may be better ultimately to separate this into two functions, and remove the $escape-reserved argument.

[69] "The % character itself is escaped only if it is not followed by two hexadecimal digits": This seems dangerous. If "%20" is a plain payload, then the '%' has to be escaped, like everything else.

Further comments from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

[87] flag to escape non-ascii or not (default should be not to unescape them).

I believe this is what we recommend but there is no default.

Discussion

See http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0048.html, http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0053.html, http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0057.html, http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0058.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0124.html.

Resolution

The most significant issue was the conditional escaping of the '%' character. Decided to align with the algorithm in the Linking spec as recommended and not escape the '%' and the '#' in the normal (escape-reserved='true') case. See member-only minutes http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/att-0171/XQ uery-157-minutes-draft.htm and http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0093.html .

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0163.html.

LC1-0105. Multiple parameters and sequences as parameters

Description

Are the conventions the same as Perl? Does the note at the end of section 1.2 need to be expanded?

Comment [13] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

Resolution

WGs discussed this on 9/18/2003 and decided that the function calling rules discussed in section 3.1.5 were clear and there was no need to add additional wording. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0032.html.

LC1-0106. fn:error

Description

How can error messages be localized?

Comment [21] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

MHK suggests note: "describing our thinking on this. A suggestion is that errors should be denoted by a QName using an application-specific namespace URI and a language-neutral local name. Implementations should provide mechanisms allowing such a QName to be translated into an error message appropriate to the user's locale." See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.html

Resolution

The WGs decided that the response from Michael Kay cited above addressed your concerns and the issue could be closed. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0034.html.

LC1-0107. fn:trace

Description

Comment [23] from the I18N WG says "Ordering implementation defined: This should be that the ordering is according to execution order, which may be implementation defined. Anything less diminishes the value of the error mechanism considerably." http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

MHK says "Saying that the order of fn:trace() output is the same as execution order and that execution order is implementation-dependent is a non-testable assertion. We should leave the current statement as it is, except that the order of output should be implementation-dependent rather than implementation-defined." See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.html

Resolution

The WGs decided that no change to the current wording was necessary. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0035.html.

LC1-0108. International rounding conventions

Description

Are international rounding conventions covered by our four functions fn:floor, fn:ceiling, fn:round anf fn:round-half-to-even?

Comment [30] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

They clearly are not. The following reference describes several rounding algorithms used in business around the world: http://www.xencraft.com/resources/multi-currency.html#rounding.

MHK says "We should consider the solution adopted in the Java BigDecimal class, which offers a choice of seven rounding algorithms, identified by a parameter to a general-purpose rounding function". See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.html

Resolution

The WGs decided that no change was needed. The languages are extensible and users or third-parties could add such functions if needed. See member-only minutes of the Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0036.html.

LC1-0109. Add URI for Unicode Collation Algorithm

Description

Add URI for basic codepoint collation algorithm (without any special tailoring). Would improve interoperability. Support may be optional.

Comment [40] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

Resolution

This was discussed by the WGs and the editors were directed to ask the I18N WG for the collation. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html. Martin Duerst replied saying that such a collation was not available now but would be available in the future. See http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0023.html. Ashok Malhotra replied saying that the editors would add a note in the status section saying that work was ongoing and an appropriate reference would be added when available. See below. See also resolution to FO-LC1-0101.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0024.html.

LC1-0110. Collation Issues

Description

Comments [45] to [49] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html. discuss issues with the F&O use of collations:

The current proposal groups three different things into a new concept called 'collation', which is different from what is usually thought of as a collation. These are:

1) A collation in the traditional sense: every binary difference leads to a non-equal match.

2) The use of different 'collations' to identify different strengths of the same collation (i.e. case-insensitive, accent-insensitive, ...)

3) The use of 'collations' to identify character combinations that serve as single units in some respect in some languages (e.g. 'll' and 'ch' in traditional Spanish)

This has several problems:

[45] - The difference between 1) and 2), and the general use of highest collation strength for sorting (to have deterministic sorting) and potentially lower for matching should be pointed out carefully.

[46] - Including 3) may make coordination with other efforts somewhat difficult

[47] - Including 3) may make implementations somewhat difficult. Although a given system (e.g. OS) may provide a range of collations (in the 1. or 2.) sense), the functionality in 3) may not be available (e.g. via an API)

[48] - Including 3) may make specifications somewhat difficult. There may be cases where it is unclear what the clusters should be. For example, for French sorting with accents in the reverse, are the clusters the base letters followed by the accents? Or is the reverse consideration of accents ignored for this purpose?

[49] - This is way too important to be relegated to a note.

Note also comment [50] - Using multiple-letter units for functions such as 'starts- with' (independent of its definition via a collation), while appropriate in some cases, may not be that well established and tested. It should be carefully considered whether this functionality may not be too 'bleeding-edge', and may not confuse users more than help, because there are too many cases where it is wrong, i.e. where character combinations are taken as single letters even if they are not, e.g. in foreign loanwords, ... For example, a possible solution may be to use codepoint matching when no collation is specified in the function rather than using the default collation.

See also #LC1-0111

Resolution

We decided to add wording to clarify our use of collations. We also decided to separate the 5 functions that use substring matching into a section of their own with a more detailed introduction. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0101.html

LC1-0111. Characters and collation units.

Description

Item [2.3] from Schema WG comments: http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html. The discussion of collation units in the second note of section 7.3 says that collation decomposes a string "into a sequence of units, each unit consisting of one or more characters", and that various comparison operations are performed on these units. The functions fn:starts-with, fn:ends-with, fn:substring-before, and fn:substring-after are all mentioned as operating on such a segmented string.

The list of functions at the beginning of section 7.4, however, describes them as operating on characters, not on the nameless collation units consisting of one or more characters each. This looks like a contradiction.

See member-only discussion thread starting with http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0039.html and the member-only proposal from Michael Kay to query-operators on 8/20. http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0058.html.

See also #LC1-0110

Resolution

This was discussed by the WGs and it was agreed that the wording needed to be clarified. It was suggested that the functions that used collation units be moved into a separate section and an optional error message be recommended. Wording should be changed as per Michael Kay's note above. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0042.html.

LC1-0112. Characters and Collation Units

Description

Final para in 7.3.1 reads: "It is possible to define collations that do not have this property, for example a collation that attempts to sort "ISO 8859" before "ISO 10646", or "January" before "February". Such collations may fail, or give unexpected results, when used with functions such as fn:contains()."

Comment [54] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html: "'this property': What property? Why 'fail'? That 'January' does not contain 'ary' would be a consequence of the definition, not a failure. Maybe it would be better to say that for fn:contains and friends, using the codepoint collation in most cases produces more predictible results than using a specific collation". Similar comment 2.3 from the XML Schema WG See http://lists.w3.org/Archives/Public/public-qt-comments/2003Aug/0003.html

MHK says "We should explain this more clearly. A URI might identify a collation that is able to compare two strings, but that does not have the capability to split the string into units suitable for use in functions such as contains(). If a collation without this capability is used as an argument to contains(), the system may reject it." See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.html.

Resolution

This was discussed by the WGs and it was agreed that the wording needed to be clarified. It was suggested that the functions that used collation units be moved into a separate section and an optional error message be recommended. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0042.html and http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0043.html.

LC1-0113. fn:subtring-before semantics

Description

For continuity, fn:substring-before($string, "") should return the empty string, and fn:substring-after($string, "") should return $string. Rationale: The shorter a string is, the earlier it generally matches. Thus, the empty string matches at the start of a string.

Comment [59] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0105.html.

MHK says "We seem to have got this wrong in substring-before, and we should change it." See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.html

Resolution

This was discussed by the WGs and it was agreed that this was a bug and should be fixed. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0140.html

LC1-0114. Facilities to check if string normalized.

Description

"Normalization checking on input and normalization on output should be available in both XQuery and XSLT, on full XML constructs (with the relevant definitions form XML 1.1)" Comment [83] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Clearly, you can normalize the string and check if the result is identical to the input.

Resolution

This was discussed by the WGs on 9/18/2003 and it was decided this was not a comment on the F&O but, rather on the language documents or the Serialization document. Please submit this comment when you review those documents. The Serialization document supports this feature. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0020.html. Francois Yergeau replies that what was requested was a function to check if a string was normalized on input http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0026.html.

LC1-0115. Canonical form for dayTimeDuration

Description

Canonical form for dayTimeDuration cannot allow leap seconds. Comment [95] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

This is a bug. Leap seconds have no place in an unanchored duration.

Discussion

This is a misunderstanding caused, perhaps, by some misleading wording that has since been corrected. Leap seconds are an artifact created to keep calendars accurate. They have no place in unanchored durations. This was discussed by the WGs and it was decided that no change was necessary. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0019.html

LC1-0116. Arguments to add/subtract duration from date/time

Description

"Add/subtract duration from date/time have operands in wrong order." Comment [105] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed by the WGs and we declined to make the change as the functions in question are op: functions not callable by the user. The order of arguments does not impact usability. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0018.html

LC1-0117. fn:resolve-QName

Description

"Allow other kinds of nodes, such as attribute nodes, as input to fn:resolve-QName." Comment [111] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed by the WGs and we declined to make the change as it merely added a bit of user convenience, not new functionality. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0016.html

LC1-0118. fn:deep-equal; comparing namespace nodes

Description

"Why are namespace nodes compared with a collation? namespaces should be compared codepoint-by-codepoint." Comment [132] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed by the WGs and we agreed to make the recommended change. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0141.html

LC1-0119. fn:default-collation

Description

If no default collation is specified, return the codepoint collation since this is the default default. Comment [147] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed in the Joint WG meeting on 9/18/2003 and it was pointed out that this was the current situation. The XQuery document says "If a Prolog specifies no default collation, the system provided default collation is chosen. If the system does not provide a default collation, the Unicode codepoint collation (http://www.w3.org/2003/05/xpath-functions/collation/codepoint) is used."

See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0012.html

LC1-0120. Casting and Construction

Description

"Why are both cast and constructor syntaxes supported?" Comment [149] from the I18N WG http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/0106.html.

Resolution

This was discussed in the Joint WG meeting on 9/18/2003 and the members of the WGs identified two situations where the casting syntax was required specifically:

1. If a user defined datatype is in the null namespace and you need to construct a value of this type.

2. If the argument to the cast may turn out to be the empty sequence.

See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Response

http://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0011.html

LC1-0121. Tests on non-existent nodes.

Description

"If you apply fn:string-length(@a) == 0; In 1.0 returns true if @a does not exist. In 2.0 returns false." Comment also says "also applies to normalize-space". Member-only comment [I42] from the XSL WG http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jul/0007.html

Resolution

This was discussed on 9/18/2003 and it was decided to change the semantics of string functions to treat the empty sequence like the zero-length string. This decision resolves this issue. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0011.html

LC1-0122. Missing date/time functions.

Description

"Is there any reason why we don't support division of a xdt:yearMonthDuration by another xdt:yearMonthDuration and division of a xdt:dayTimeDuration by another xdt:dayTimeDuration? Also, why isn't it possible to subtract two dates from each other to get a xdt:yearMonthDuration (rather than a xdt:dayTimeDuration)?" See member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Aug/0059.html

This has segued into a thread on whether we need a function or should allow casting from a number or two numbers to xs:duration, xdt:yearMonthDuration and xdt:dayTimeDuration.

Resolution

This was discussed on 9/18/2003 and it was decided to bundle this with FO-LC1-0058, which suggests that the two fully-ordered subtypes of xs:duration be removed and functions on those datatypes be replaced by numeric functions. See member-only minutes of Toronto meeting: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0154.html.

At the joint WG meeting yesterday we decided to postpone consideration of Michael Kay's proposal to the next version of the document. See member-only note http://lists.w3.org/Archives/Public/public-qt-comments/2003Sep/0114.html. See member-only minutes of meeting http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0011.html. Thus, this related issue should be postponed as well.

Response

Member-only note http://lists.w3.org/Archives/Member/w3c-query-operators/2003Oct/0005.html