XPath 2.0 and XQuery 1.0 Issues

XPath can't be treated as a terminal symbol in our grammar. We intend XQuery to be a superset of the abbreviated syntax of XPath. We do not use the grammar of XPath directly because it needs to be integrated into our other productions. For example, operators like the union operator, which occur in path expressions, also occur in other contexts in XQuery, and it makes little sense to define two different operators. This raises issues of coordination with XPath.

This is the charter of the XPath task force.

The XQuery editorial team is working through a number of cases to determine the best precedence of operators. Our current precedence rules are shown in Appendix B.

Operator precedenced subsumed by XPath 2.0 WD.

What should be the precedence of a RangeExpr? The XQuery grammar has it in a bit different place than is listed here.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)

Current grammar ok.

Jerome and Mary have suggested that we abandon the separate abstract syntax for XQuery, in favor of a higher-level BNF.

This is the BNF that now appears in Appendix B.

This is the BNF that now appears in Appendix B.

XPath 1.0 has no reserved words. The current XQuery spec attempts to avoid reserved words but the result is that the XQuery grammar relies heavily on lexing tricks that make it difficult to document and difficult to extend. There is currently a substantial feeling in the XQuery group that the language should have some reserved words, which would be an incompatible change from XPath 1.0.

XSL WG Position: Exceptionally strong feeling that requiring element names that match a reserved word to be escaped is utterly unacceptable. If reserved words are required they must start with an escape character so they cannot conflict with element names. Attempt to maintain grammar and revisit this issue as necessary. We recognize that there is a problem but solutions are all distasteful.

Cf. 5. Reserved Words:

Subsumes: #xquery-xpath-issue-reserved-words.

Cf. Keywords in XQuery

Subsumes: #xquery-reserved-keywords.

Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0252.html)

Decision by: xquery on 2002-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)Joint F2F

Decision by: xsl on 2002-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)Joint F2F

Closed with no change to document.

XPath 1.0 has no reserved words. It might be desirable to relax this restriction in XPath 2.0. When it is necessary to use an identifier that string-matches a reserved word, the identifier could be prefixed by a colon to distinguish it from a reserved word, as in /investment[:return > 0.1]. Reason: most query and progamming languages have reserved words. The only way to avoid them is to introduce lexing "tricks" that make the grammar difficult to document and difficult to extend. This approach greatly increases the difficulty of implementing an XQuery parser. It also contradicts the generally accepted practice of cleanly separating the parser from the lexer and keeping the lexer as simple as possible. It may also interfere with the parser's ability to report on and recover from errors.

Status: Open and under discussion. No consensus at this time.

Subsumed by :xpath-issue-reserved-words.

Where should keywords be reserved in XQuery? Currently, they are not reserved in the XML portion of our grammar, but are reserved in the expression syntax. XPath also reserves keywords, but only in certain positions in expressions.

Subsumed by :xpath-issue-reserved-words.

Should keywords in XQuery be case-sensitive?

Decision by: xsl on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)

Decision by: xquery on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)

Keywords are case-sensitive and it was also decided to use only lower-case keywords in the current XQuery / XPath WD. Thtopchange the text, the grammar, and the examples.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft: section 2.1.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

There has been deep discussion about the issue of implicit conversions, the effect of which is pervasive in XPath. The advocates for implicit conversion cite XPath 1.0 compatibility, ease of use for very common operations, and issues associated with types specified by the source tree when a schema is present, and the fact that these types may not be known at compile time. The detractors cite hidden 'gotchas' with the implicit conversion, and some difficulty in regards to optimization rewrites. The current document defines normative implicit conversions, but places the responsibility on whether or not these conversions will be done, or an error thrown, on the XPath context.

Addressed by XPath 2.0 basic and standard-fallback conversions. Whether or not implicit conversion is done when a type error occurs is up to the host language to define.

Consider the expression price * 2. If price evaluates to a node-set containing more than one node, XPath 1.0 extracts the numeric value of the first node and multiplies it by two, but XQuery will probably raise an error in this case. Tentative proposal: if we can get XQuery to accept the default XPath 1.0 conversion, but require explicit conversion for XQuery, it should solve this problem.

Addressed by XPath 2.0 basic and standard-fallback conversions. This is no longer an issue since both operands must be singletons.

XPath has a number of implicit type coercions, and also has implied existential quantification in some places. In XML 1.0, which had a small and loose type system, this was less problematic than it is with XML Schema, which introduces many types and relationships among types. If XQuery is to be compatible with XPath, we need to study these rules carefully, and adapt them to be rational and intuitive when used with the XML Schema type system.

Also, there are interactions between quantification and type coercion in XPath, sometimes causing non-intuitive results.

Addressed by XPath 2.0 basic and standard-fallback conversions.

XQuery-Null-Issue-3: Question: What should happen if an operand of an arithmetic operator is a sequence of length greater than 1?

Addressed by XPath 2.0 basic and standard-fallback conversions. It's an error.

Text is in Working Draft 2001-11-28 sec 2.5.

If two sequences are combined with an arithmetic operator, what are the semantics? Should a Cartesian product be used? Should the operator be applied to pairs? Should an error be raised?

Text is in Working Draft 2001-11-28 sec 2.5.

Addressed by XPath 2.0 basic and standard-fallback conversions. It's an error. See also: #xquery-xpath-arith-on-sets

Some feel that something as fundamental as type error checking should not be part of the context. This will prevent expressions from being moved between XSLT and XQuery without changing their results.

We recognize that XQuery may have a different conversion strategy but feel this proposal gives them that flexibility. For Xpath implicit conversions are considered to be exceptions which allow a host language to specify that the processor either halt or continue with the conversion as the recovery action. If this exception could occur at runtime the processor is allowed to notify the user earlier. (Allows static type checking).

In XPath 1.0, a node-set can be used in a Boolean context, and it is considered to have the value True if it is non-empty. But XQuery believes that a node-set containing one element with value False should not be implicitly converted to True. For example, if married is a Boolean-valued subelement of person, XQuery does not believe that //person[married="True"] should return persons whose married subelement has value False.

The section on comparisons performs exceptional treatment for node-set to Boolean conversions. Jonathan Marsh does not support such an exception. Either we should remove the exception and take the backward compatibility hit, or we should define a different mechanism to access the typed-value so that the compatibility question is avoided.

Input from Michael Rys:

The following proposal tries to provide a solution to the following
issues:

XPath2-Issue-14 (node-set-conversion): Implicit conversion of node-sets
to boolean for comparisons.
Priority: 1 Originator: XQuery, jmarsh@microsoft.com Locus: Syntax

XQuery-XPath2-Issue-2 Converting node-sets to Boolean.

XQuery-Issue-64 Converting general expressions to boolean

and is related to the following issues:

F&O Issue 85 : The semantics of xf:boolean(node) is underspecified
(operator-boolean-node-unspecified)

We would appreciate if this could be scheduled quickly and accepted.

Assumptions
-----------

I use the function typed-value(node) from the data model as a synonym
for the actual language accessor /data().

Problem description
-------------------

XPath 1.0 defines an implicit conversion of node-sets N to boolean in a
way that any such conversion is defined as not(empty(N)). This is a
useful definition for being able to define node tests of the forms

(A) a[@b]
(B) a[b or b/c = 4]

but unfortunately conflicts with the general rules of typed-value access
as requested by XQuery for expressions such as

(C) a[@b=$val]

In such expressions, if $val is bound to an integer value expression
then the expected rules are:

let $val := 5
return a[@b=$val]

becomes (after expression rewrite and implicit typed-value access):
a[typed-value(@b) = 5]

If $val binds to a boolean value, the same expression unfortunately is
in contradiction with the XPath 1.0 semantics:

let $val := xf:false()
return a[@b=$val]

becomes (after expression rewrite and implicit typed-value access):
a[typed-value(@b) = xf:false()]

XPath 1.0 semantics would be:
a[not(empty(@b)) = xf:false()]

Summary of the proposal
-----------------------

The following proposal tries to preserve the XPath 1.0 semantics for
cases (A) and (B) while preserving the typed-value access for case (C).

Impact: It will preserve XPath 1.0 backwards-compatibility for the 80%
use case but break it in the 20% use case.

Details
-------

1. Generally, if a node or node sequence is passed as a parameter to a
function or operator where a boolean value is expected, an attempt is
made to extract the typed-value of the node(s) subject to the conversion
rules of the nodes type to boolean.

Comment: This will cover (C) to be always a[typed-value(@b) = $val]
regardless of the type of $val.

2. The following exceptions hold:
2 (a) If the operation is a predicate (either the [] shortform or the
where clause in FLWR), then a node or node sequence will be translated
into a node test instead of accessing the typed value.

2 (b) If the operation is the not() function or the and or or operators,
an argument expression that results in a node or node sequence will be
translated into a node test instead of accessing the typed value.

Comment: This will preserve the useful XPath 1.0 compability for cases
(A) and (B). Note that we have special cased these operations already,
so the special casing is less of a problem than it may seem.

Open Issues
-----------
The XPath 1.0 semantics uses xf:boolean(node) to define the node test
semantics. XQuery's cast currently does not clarify if it performs
implicit typed-value access on CAST as xsd:boolean (node) or if it is an
error (to allow casting to user defined complex types in the future). In
either case it does not perform a node test.

The question is whether xf:boolean in XPath 2.0 should be the node test
or CAST as xsd:boolean(typed-value(node)). I prefer the later, but am
open to strong pushback.

Cf. Consistency of functions that take boolean formal argument

Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)

Agreed that choice context is not necessary for XPath predicates. Standard fallback conversions will handle case when required value is optional boolean but actual value is not.

Decision by: xpath-tf on 2001-11-13 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0065.html)

Adoption of Michael R's proposal in Proposal to close issue expr[nodes].

Decision by: xpath-tf on 2001-11-20 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0114.html)

There have been some problems called to attention on the editor's list about the decision made at the telcon concerning dealing with nodes in predicates and the like.

The issue will be discussed at the F2F meeting.

Text is in Working Draft 2001-11-28 sec 2.3.

Text is in Working Draft 2001-11-28 sec 2.7.

Text is in Working Draft 2001-11-28 sec 2.11.

Text is in Working Draft 2001-11-28 sec 2.12.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)

Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0692.html)(joint meeting)

Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0692.html)(joint meeting)

The EBV of a sequence containing both nodes and atomic values is True.

In XPath 1.0, a node set can be used in a Boolean context, and it is considered to have the value True if it is non-empty. This feature is sometimes used in predicates; for example, //person[kid] returns persons who have a kid. In the XPath-2 data model, it is possible to have a sequence of Booleans, or a sequence of elements whose values are Booleans. It is very strange for a sequence containing the single value False to be interpreted as True, or for a sequence containing one node whose value is False to be interpreted as True. For example, consider the query //person[married=True]. It seems unfortunate for this query to return a person containing a single "married" element whose value is False.

This is a difficult problem. Here are some possible approaches, all of which have disadvantages: a. Retain the current XPath 1.0 semantics. Problem: then //person[married=True] returns persons whose "married" subelement has value False. b. If the sequence contains exactly one element whose content is Boolean, extract the value; otherwise raise an error. Problem: incompatible with existing usage such as //person[kid]. c. Use rule (a) above when a node-sequence is used directly in a predicate such as //person[married], but use (b) above when a node-sequence is used with any Boolean operator, as in //person[married=True]. Problem: inconsistent rules. d. Change XPath so that values are not extracted from nodes except by an explicit data() function. Then, for example, a person containing a married subelement with value False would be returned by the query //person[married] but not by the query //person[married/data()=True]. The query //person[married=True] would be a type error. Problems: this approach is incompatible with XPath 1.0, and it annoys users by requiring them to type salary/data() + bonus/data() rather than salary+bonus.

Status: Open. For discussions of this issue, see http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Sep/0137.html and http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Sep/0160.html.

Subsumed by :xpath-issue-node-set-conversion.

Conditionals in XQuery allow any expression in the grammar. Which kinds of expressions are actually converted to Boolean values, and how is this done? Which kinds of expressions raise errors?

Subsumed by #xpath-issue-node-set-conversion.

XPath 1.0 implicitly converts a node set to a number by using the value of the first node. XQuery suggests that, in XPath 2.0, conversion of a node set to a number should raise an error if the node set contains more than one node. Reason: the current XPath 1.0 rule leads to lots of strange behavior. For some examples, consider the following queries, against a document containing persons who have unique names but possibly multiple donations: //person[name="Hillary"]/donation returns all the donations of Hillary. //person[name="Hillary"]/donation+0 returns only the first donation of Hillary. //person[donation] returns all persons who have a donation. //person[donation+0] returns only those persons whose position in the list of persons is equal to the value of their first donation. Editorial note: Some people have observed that example (c) above illustrates conversion of a node set to Boolean rather than arithmetic on node sets. I have retained these examples here because the difference between examples (c) and (d) illustrates an interesting property of arithmetic on node sets in XPath 1.0.

Subsumed by #xpath-issue-node-set-conversion. Status: The Query WG approved this request on 9/19/01.

Sequences are defined to not be able to contain sequences. Yet, it is probably that we need to be able to represent null in sequences in order to maintain cardinality for table processing and the like.

Proposal: Nulls are a special value or an empty sequence: It is a special value when it is a member of a sequence. It is an empty sequence for type checking and iteration. This may require tagging empty sequences that were returned as null with a flag. The XSL WG has not reached resolution on this proposal.

Conflicts with : null-missing-data.

Decision by: xpath-tf on 2001-12-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Dec/0128.html)

Decision by: xquery on 2001-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0150.html) confiriming that no action is required by the XQuery WG

XSLT WG agrees that empty sequence should be used to represent missing data (this is the status quo).

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

How should missing or unknown data be represented?

Subsumed by: #xpath-issue-null-value. Resolution: by an empty sequence.

Should elements with xsi:nil="True" receive any special treatment on input?

Resolution: In the case of an empty element whose content-type is string, the attribute xsi:nil will be used to distinguish the zero-length string from the empty sequence. For example, <a /> indicates an element whose content is the zero-length string, while <a xsi:nil="True" /> indicates an element whose content is the empty sequence.

In XPath 1.0, boolean operations such as AND and OR are defined using two-valued logic. In order to effectively deal with absent or unknown data, XQuery will probably introduce three-valued logic as used in SQL, using an empty sequence to represent the unknown truth value. This would result in incompatible changes to Boolean operators such as AND and OR.

The XSL WG resolved that three-valued logic should be used.

What logic should be used by the AND and OR operators?

Subsumed by: #xpath-issue-3valued-logic. Resolution: Three-valued logic using SQL truth tables.

In XPath 1.0, operators such as AND and OR are based on two-valued logic and an empty sequence is considered to have the truth value False. XQuery suggests that, in XPath 2.0, the Boolean operators use three-valued logic with the empty sequence representing the unknown truth value. Reason: This change will allow XQuery to deal effectively with missing and unknown information. This is a long-standing requirement that is handled by null values in relational systems. It is convenient to represent missing information by an empty sequence in the XQuery data model rather than by introducing a separate null value. However, this approach leads to some differences from XPath 1.0 usage, including the following, where () represents the empty sequence: True AND () has the value (), whereas in XPath 1.0 it is False. False OR () has the value (), whereas in XPath 1.0 it is False. not( () ) has the value (), whereas in XPath 1.0 it is True. () = () has the value (), whereas in XPath 1.0 it is False. Status: The Query WG approved this request on 9/19/01.

Personal observation (by Don): XPath 1.0 has a not() function but it does not have a NOT operator. It would be possible to retain the not() function with two-valued logic and introduce a new NOT operator with three-valued logic.

Subsumed by: #xpath-issue-3valued-logic.

Does XQuery need three-valued logic? How should XQuery deal with missing or absent values? What are the semantics of XML Schema's xsi:nil?

Subsumed by: #xpath-issue-3valued-logic.

The section on Conditional Expressions provides for if/then/else but not a simple if/then. Should we default then to return an empty sequence?

See also: null-if-where.

Decision by: xpath-tf on 2002-01-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0312.html)

Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)

Decision by: xsl on 2002-02-07 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Feb/0034.html)

No change to if-then-else.

What is the behavior of IF and WHERE if the value of the branch-expression is the empty sequence?

Subsumed by: #xpath-issue-if-not-else. Resolution: IF takes the ELSE branch. WHERE does not execute the RETURN clause.

Should the 3-valued logic functions be part of the XPath function library? Note that they can be implemented as user functions (not as efficient as a "native" implementation). We may want to include the user definition as an example.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)

Not for XPath 2.0/XQuery 1.0.

What value is returned by not() when called on an empty sequence?

Notes: In XPath 1.0, not() is a function that uses two-valued logic, where not() applied to an empty sequence returns True. This feature of XPath 1.0 is sometimes used to test for the absence of a node. The XSLT group has suggested that we retain the semantics of not(), and introduce a new function named not3() based on three-valued logic. XPath 1.0 has no NOT operator in its syntax. Therefore XQuery could add a NOT operator that uses three-valued logic without introducing an incompatibility with XPath 1.0. Option 9A: not() should implement 3-valued logic, an incompatible change to XPath 1.0. Option 9B: not() should implement 2-valued logic and a new function not3() should implement 3-valued logic. Option 9C: Same as 9B, and in addition XQuery should introduce a NOT operator into the syntax, using 3-valued logic with the SQL truth table. History: The XQuery group voted for (9A) at the Redmond F2F, but subsequent inputs from the XSLT group merit reopening this issue.

Subsumed by: #xpath-issue-not-logic.

For functions, the null (empty sequence) is passed to the function, the precedent set by SQL. Should comparison operations act the same, or should they be defined to always return an empty sequence in this case?

Text is in Working Draft 2001-11-28 sec 2.6.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

In XPath 1.0, two empty sequences are considered to be equal. However, since XQuery plans to give the empty sequence a special meaning similar to the null value in SQL, XQuery considers comparison of two empty sequences to return the unknown truth value.

Resolved as per three-valued logic. The XSL WG does not believe there are backwards compatibility issues here, since in XPath 1.0, $x=$x is false if $x is an empty node-set. This is a consequence of implicit existential quantification.

Is for really a proper construct for a simple expression language? Will the definition of for in XPath cause problems for XQuery?

Input from Michael Kay:

Decision by: xpath-tf on 2001-11-27 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0167.html)

Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)

Adoption of FOR expression in XPath 2.0.

Scott Boag will provide 'tips & traps' text on potential semantic problems of mixing FOR, '/' and SORT.

Text is in Working Draft 2001-11-28 sec 2.9, paragraph 2.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

The simple form of the for expression (for( sequence ) return expression) introduces a lot of complexity: the "context item" is required for this, and there is an issue with the parens being required for the simple varient, and not being required for the more complex one. Do we need this?

Subsumed by: #xpath-issue-is-for-required.

The syntax for the "for" expression currently does not define a range variable. An alternative syntax might be "for ($item) in expr return $item/@price*$item/quantity".

XSL WG: We suspect we will need both, since we feel that range variables will be needed to do joins, but requiring range variables causes a great deal of verbosity.

Subsumed by: #xpath-issue-is-for-required.

A FOR clause can stand alone: FOR $var IN expr1 RETURN expr2. A LET clause can stand alone: LET $var := expr1 EVAL expr2. It has been suggested that a WHERE clause should also be able to stand alone: WHERE expr1 RETURN expr2.

Note: in the current BNF, at least one FOR or LET clause must occur, but it is not necessary to have a FOR.

Observation: This functionality is already provided by the conditional expression, IF expr1 THEN expr2 ELSE [ ]. There does not seem to be a compelling reason to provide a second way to write this expression. However, making the ELSE clause optional might be a slight improvement.

The following content model should be adopted for FLWR expressions:

FlwrExpr ::= (ForClause | LetClause)+ [WhereClause] ReturnClause

This allows us also to remove the separate LET/EVAL expression, which can now be expressed using LET/RETURN.

The following content model should be adopted for FLWR expressions:

FlwrExpr ::= (ForClause | LetClause)+ [WhereClause] ReturnClause

This allows us also to remove the separate LET/EVAL expression, which can now be expressed using LET/RETURN.

We have considered forms of quantified expressions that bind several variables at once, as in SOME $x IN expr1, $y IN expr2. Are such quantifiers desireable? If so, what are their semantics, and what use cases support them? Note that there is no additional expressive power over the current single-variable syntax, this is purely a question of convenience.

Decision by: xpath-tf on 2001-12-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Dec/0128.html)

Allow them; especially in view of consistency with eg "for" that already allows them. The semantics should be the same.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

XPath 1.0 has only four datatypes (booleans, floating-point numbers, strings, and unordered node-sets). XQuery suggests that XPath 2.0 should have a richer set of datatypes based on the built-in types of XML Schema and the notion of an ordered sequence, which can contain zero or more simple or complex values. Literal values should have well-defined datatypes that are determined by their appearance. This will require some changes in the interpretation of literals. For example, 47 will be a literal integer rather than a float. Some types will have constructor functions rather than literals; for example, date("1999-12-25") is distinguished from the arithmetic expression 1999-12-25 which has value 1962. Reason: these changes are needed in order to process documents based on XML Schema.

Status: The Query WG approved this request on 9/19/01.

XPath 2.0 to support all XML Schema primitive datatypes.

Text is in Working Draft 2001-11-28 sec 2.2.1.

The set of constructor functions for XML Schema simple datatypes has not yet been established. A joint task force with XML Schema has been chartered to determine the operators on datatypes, and we expect them to also determine the set of constructors for datatypes.

Resolved in F&O document.

A fixed "promotion hierarchy" must be defined among the primitive and derived types of XML Schema. A function whose declared parameter type is in this hierarchy can be invoked with an argument whose type is lower in the hierarchy. For example, a function with a declared parameter-type of Float can be invoked with an integer argument. In such a case, the argument is converted to the declared type of the parameter.

The promotion hierarchy will be defined by the Operators and Functions Task Force.

Resolved in F&O document.

Section 2.9, on functions, portrays XQuery as a statically typed language, but the mechanisms by which static typing is established are still being developed by the XML Query Algebra editorial team. A complete accounting for type requires that the XML Query Algebra conform completely to the XML Schema type system, and that many open issues be resolved.

The semantics of XQuery are defined in terms of the operators of the XML Query Algebra. The mapping of XQuery operators into Algebra operators is still being designed, and may result in some changes to XQuery and/or the Algebra. The type system of XQuery is the type system of XML Schema. Work is in progress to ensure that the type systems of XQuery, the XML Query Algebra, and XML Schema are completely aligned. The details of the operators supported on simple XML Schema datatypes will be defined by a joint XSLT/Schema/Query task force.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

We have made significant progress. There is still some mismatch (eg. occurrence indicators and facets), but these are also unlikely to change.

Decided: close this issue, raise more specific issues as needed.

Static type checking and schema validation are not equivalent, but we might want to do both in a query. For example, we might want to assert statically that an expression has a particular type and also validate dynamically the value of an expression w.r.t a particular schema.

The differences between static type checking and schema validation must be enumerated clearly (the XSFD people should help us with this).

This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00970097.

Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

Addressed by the "Named Typing" proposal.

Accepting text in 2002-04-30 public draft.

Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.

Static type checking may be difficult and/or expensive to implement. Some discussion of algorithmic issues of type checking are needed. In addition, we may want to define "conformance levels" for XQuery, in which some processors (or some processing modes) are more permissive about types. This would allow XQuery implementations that do not understand all of Schema, and it would allow customers some control over the cost/benefit tradeoff of type checking.

This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00980098.

Jonathan and Don to present a potential consensus proposal at the f2f (This should be a very short proposal). Note: Perhaps we should seriously consider writing the conformance section for the next set of publications.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decided: Adopt the text in the conformance section of the latest document.

We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.

The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Closing of the directly related issues: #xquery-abstract-syntax and #xpath-issue-complex-type-value is sufficient to close this issue.

Decision by: xpath-tf on 2003-03-04 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0060.html)

Decision by: xsl on 2003-03-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

On recommendation of the Processing Model Taskforce the disposition is reaffirmed.

This is related to #xquery-schema-importxquery-schema-import. We do not specify what is the effect of type checking a query that is applied to a document without a DTD or Schema. In general, a schema-less document has type xs:AnyType and type checking can proceed under that assumption. A related issue is what is the effect of type checking a query that is applied to an incompletely validated document. As above, we can make *no* assumptions about the static type of an incompletely validated document and must assume its static type is xs:AnyType.

This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00960096.

Some aspects addressed by the "Named Typing" proposal.

The Data Model work still needs to be done.

Open questions: What is the result of a failed validation? Can you inspect the result?

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

a. The Data Model mapping is the crucial issue - and that is duplicated in 43 (xquery-define-schema-variants), so we need not continue to maintain it here.

b. The second issue asks how we process documents on which validation has failed. Open a separate issue (xquery-failed-validation) on this question.

Does the definition of a type include both element-names and element-contents (as in the Formal Semantics document), or only element-contents (as in XML Schema)?

Addressed by the "Named Typing" proposal.

Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

Accepting text in 2002-04-30 public draft.

Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.

Do we need a function that returns the type name of its operand? If so, what should it return if the operand is an element with a given xsi:type - the element name? the name of the type denoted by xsi:type? Specification of this function requires more work on types in XQuery.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Not for XQuery 1.0.

Should XQuery 1.0 support subtype substitutability for function parameters?

If subtype substitutability is not supported in XQuery Version 1, the motivation for TYPESWITCH is weakened and the decision to support TYPESWITCH should be revisited.

Input from Michael Rys:

I think this is still an open issue given some semantic issues that we
found between named subtype substitutability and derivation by
extension. I will send mail on this issue this week,

Addressed by the "Named Typing" proposal.

Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

Accepting text in 2002-04-30 public draft.

If the types in the CASE branches are not subtypes of the TYPESWITCH, is this an error, or are these branches simply never executed? If the latter, should we require a warning?

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

Issue 48 closed without changes to the document (no static errors will be raised, implementations can but are not required to raise warnings).

Decision by: fs-editors on 2003-02-13 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Feb/0075.html)

Decision by: xquery on 2003-02-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0404.html)

Decision by: xsl on 2003-02-27 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0143.html)

Accepting proposal in FS-Issue-0173 closes this issue in a consistent way.

How should XQuery handle XML Schema substitution groups with respect to name tests in paths? With respect to parameter types and return types in functions?

Text is in Working Draft 2001-11-28 sec 2.13.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

We need more thought about what constitutes a valid parameter-type for a function. Attribute-types as well as element-types? Type-names vs. element-names? Should all the MSL symbol spaces be represented? Wildcards? Sequences?

It is probably important to have NODE as a type, to allow functions to take any XML node as a parameter, or to return any XML node as a result.

Using univeral names similar to those found in the MSL document, but with a different syntax, would allow us to reference any schema type in XQuery function definitions.

Text is in Working Draft 2001-11-28 sec 3.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

More detailed rules need to be developed for function resolution. What kinds of function overloading are allowed? A promotion hierarchy of basic types needs to be specified. The issue of polymorphic functions with dynamic dispatch needs to be studied. Can overloaded functions be defined such that the parameter-type of one function is a subtype of the parameter-type of another function? If so, what are the constraints on the return-types of these functions? Is function selection based on the static type of the argument or on the dynamic type of the argument (dynamic dispatch, performed at execution time)? If XQuery supports dynamic dispatch, is it based on all the arguments of a function or on only one distinguished argument?

Observation: This is a very complex area of language design. If it proves too difficult to solve in the available time, it may be wise to take a simple approach such as avoiding dynamic dispatch in Version 1 of XML Query.

The XML Query Formal Semantics does not support overloading or dynamic dispatch. We will attempt to simplify XML Query Level 1 by omitting these, unless it becomes clear that they are needed. We realize that this might happen.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

Mike: We dealt with by saying that there is only one function and the use typeswitch semantics.

Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.

XQuery currently considers book and list(book) to be different types. List is an abbreviation of the facets minoccurs=0, maxoccurs = unbounded. We need to confirm that this accurately reflects the type system of XML Schema.

Data model and type system both have sequences. This seems a moot issue.

NOTE: the original formulation of the question is in vocabulary that makes no sense in terms of the actual resolution. Thus the formulation of the issue is confusing, and it is only the resolution that matters.

Does XQuery need features to add support for unordered collections? If so, what features are required? In the current draft, "unordered" is a property of a list. The user can create an ordered list from an unordered list by using SORTBY. The distinct() function not only removes duplicates from a list, it also renders the list unordered.

Do we need a function that merely removes the ordered property of a list?

How does the ordered/unordered property of a list affect the semantics of operators applied to it?

XQuery editors considered and rejected addition of an unordered collection and type. The data model and type system support ordered sequences only.

Is it an error for a query to specify content that may not appear, according to the schema definition? Consider the following query:

invoice//nose

If the schema does not allow a nose to appear on an invoice, is this query an error, or will it simply return an empty list?

Addressed by the "Named Typing" proposal, but needs more work.

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Adopt status quo.

As part of the general description of errors, which is largely still to be done, we must carefully distinguish static from dynamic errors. In general, we should probably attempt to catch errors as early as possible. The following examples have been suggested by the Algebra team:

"If the content of its argument node cannot be expressed as a value of a simple type, the data function raises an error." This could be a static error, since the data function makes most sense for schema valid documents or nodes that have type assigned via xsi:type.

"For each member of the sequence, the ordering expression must return a single value of some type for which the ">" operator is defined (for example, a number or a string); otherwise an error results." This could also be a static error.

"When one or more operands is a node, the content of the node is extracted by an implicit call to the data function and converted to a number before the operation is performed; if this conversion is not possible, an error results." This could be a static or a dynamic error.

"TO is a binary operator that converts both of its operands to integers. It then generates a sequence containing all the integers from the left-hand operand to the right-hand operand, inclusive. If either of the operands cannot be converted to an integer, an error results." In the presence of type info, this could be a static error. In a well-formed document, in which arbitrary strings may be converted to integers, it could be dynamic.

Text is in Working Draft 2001-11-28 sec 3.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:

1. Are type names sufficient, or does XQuery really need its own syntax for declaring types?
2. Would Normalized Universal Names (derived from MSL) be sufficient for type names?
3. How will type names be bound to definitions?

Decision by: xquery on 2003-01-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0215.html)Joint F2F

Decided:

Are type names sufficient - YES

Would NUNS be sufficient for type name - not needed

How will type names be bound to definitions - with imported schemas and namespaces

Do we need to allow inline XML schema declarations in the prolog of a query? The following example shows one potential syntax for this. It extends the namespace declaration to allow literal XML Schema text to occur instead of a URI in a namespace declaration. The implementation would then assign an internal URI to the namespace.

                  NAMESPACE fid =
                  "http://www.example.com/fiddlefaddle.xsd"

  NAMESPACE loc =  [[
      <xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">
      <xsd:simpleType name="myInteger">
      <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="10000"/>
      <xsd:maxInclusive value="99999"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:schema>
  ]]


  FUNCTION string-to-myInteger ($s STRING) RETURNS loc:myInteger
  {
   If the facets of loc:myInteger are not satisfied,
   this function raises an error.

    LET $t := round(number($s))
    RETURN TREAT AS loc:myInteger($t)
  }


  string-to-myInteger("1023")

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Not for XQuery 1.0.

We do not specify how a Schema or DTD is 'imported' into a query so that its information is available during type checking. Schema and DTDs can either be named explicitly (e.g., by an 'IMPORT SCHEMA' clause in a query) or implicitly, by accessing documents that refer to a Schema or DTD. The mechanism for statically accessing a Schema or DTD is unspecified.

This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00950095.

Text is in Working Draft 2001-11-28 sec 3.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

The semantics of the instanceof operator are not defined over all operands, e.g. sets of several nodes, sequences of several values, etc. What should the symantics be for these types? Should these semantics be defined in the F&O document?

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html)

The issue is "dead", in the sense that the April draft contains text that everyone is happy with.

Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.

Does XQuery need a CAST expression for casting an instance of one type into another type?

A "CAST AS" operator has been added to this current Working Draft.

It's not clear to me that we need "cast" syntax, this can be done using the functions whose names match the primitive data types.

We decided that the constructor pseudo-functions should only take literal arguments, therefore CAST is needed for run-time conversions (the original issue was saying that we didn't need both)

The algebra does not have coercion functions between values. The mapping requires this for CAST AS.

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core, therefore includes CAST AS.

Does XQuery require a syntax for type guards?

We have added the "TREAT AS" operator to this current Working Draft. This is especially helpful for function arguments, since we do not have function polymorphism in the current specification.

The functionality of TREAT can also be expressed using TYPESWITCH. A proposal to remove the TREAT expression is under consideration.

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. 'TREAT AS' is expressed in XQuery core as a TYPESWITCH.

Various approaches to the syntax of CAST AS and TREAT AS have been proposed. Java and SQL have both been sources used to discuss these approaches. We are still exploring other syntactic approaches.

CAST/TREAT syntax has been pretty stable for a while. Can we just resolve this issue?

Do we need an expression similar to the MATCH expression in the algebra? One proposed syntax looks like this:

TYPESWITCH expr
                CASE typename1: expr1
                CASE typename2: expr2

Since this syntax corresponds more closely to the syntax of the algebra, it can be mapped more easily. Alternatively, the match expression in the algebra could be made to resemble the INSTANCEOF expression of XQuery.

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. TYPESWITCH is supported in both.

In the XQuery Formalism document, there is a static type-assertion expression:

Expr : Type

This is often useful in an expression like:

LET bib0 : Bib := <bib>...some literal data...</bib>

which asserts statically that the type of bib0 is Bib, i.e., that the literal data is a value contained in the Bib type. If this is not true, a static, compile-time error is raised.

This semantics is not the same as :

LET bib0 := TREAT AS Bib (<bib>...</bib>)

which will raise a run-time error if the literal data is not a value in Bib.

Current proposal is for ASSERT AS Datatype (Expr)

Text is in Working Draft 2001-11-28 sec 2.13.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

Do we need a Context Item to track the "current item" in a for itteration, and, if so, how should it work? How should "." work in relation to it?

Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)

Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)

Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)

Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)

Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.

Do we need a way to specify the nodes in the input context? Many queries do not specifically state the input to which they will be applied. This allows the same query, for instance, to be applied to a number of databases. It may be helpful for the mapping to introduce a global variable, eg $input, to represent the input nodes for a query. This variable might even be useful in the syntax of XQuery itself.

Decision by: xquery on 2002-05-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0104.html)

The imput() function provides this functionality.

It seems like the context should include a default namespace declaration for use for the QNames within node tests within the XPath. I'm worried about complexities with other qnames besides the one in node tests, like function qnames.

Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)

Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)

Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)

Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)

Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 5.

Do we need a datatype names binding in the context?

Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)

Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)

Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)

Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)

Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 8.

The Functions and Operators doc specifies named collations. These probably need to be part of the context. 1) Should we treat collations as distinct from functions? 2) If yes, how do we handle the binding of the collation name to the collation.

Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)

Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)

Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)

Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)

Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 11.

How are collation sequences created to define inequality and sort orders?

Subsumed by: #xpath-issue-collation-bindings.

The definition and syntax of a query module are still under discussion in the working group. The specifications in this section are pending approval by the working group.

Future versions of the language may support other forms of query modules, such as update statements and view definitions.

Paulist Modules Proposal

This proposal adds modules, external variables, external functions,
and global variables to XQuery. It addresses the following open
issues:

   74 Module syntax
   75 Importing Modules
124 External Functions
157 Function Libraries
223 We need a way to declare external functions
250 Declaring Variables in Prolog

This proposal is called the Paulist Modules Proposal, because it is
based on a simplification Paul Cotton made to earlier module
proposals, which can be found here:

  Subject: Paul's Proposal (was: Unified proposal on modules, global
           and external variables, and external functions)
  From: Jonathan Robie (jonathan.robie@datadirect-technologies.com)
  Date: Thu, Dec 19 2002
  http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0391.html

Many other people have contributed to this proposal in various
iterations, including Mary Fernandez, Jerome Simeon, Don Chamberlin,
Michael Rys, Phil Wadler, and Michael Kay.


1. Modules and Module Declarations

    An XQuery module is a resource that contains a Query. A module may
    declare a target namespace using a ModuleDecl. The syntax of Query
    and ModuleDecl is as follows:

      Query ::= ModuleDecl? QueryProlog ExprSequence?
      ModuleDecl ::= "module" ModuleURI

    If a module contains a ModuleDecl, its functions may be imported by
    other modules. A module that does not have a ModuleDecl can not be
    imported. A ModuleURI may be relative - if so, it is combined with
    the Base URI to create an absolute URI.

    In a module that is imported by another module, the optional
    ExprSequence must be absent, or a static error is raised.

2. Module Imports

    A query may import modules in the QueryProlog using
    ModuleImports. The syntax of QueryProlog and ModuleImport is as
    follows:

      QueryProlog ::=  (NamespaceDecl
                       | DefaultNamespaceDecl
                       | SchemaImport
                       | ModuleImport
                       | VarDn)*
                       FunctionDn*

      ModuleImport ::= "import" "module" ModuleURI ("at" ImplURI)?

    Functions and global variables defined in a module may be used in
    any module that imports the defining module. Importing a module
    does not provide access to the imported schemas or namespaces of
    that module. Importing a module does not provide access to the
    functions imported by that module.

    An implementation may locate a module in any convenient manner,
    provided the ModuleURI of the module it locates matches the
    ModuleURI of the ModuleImport. The optional ImplURI specifies the
    resource containing the implemenation of the module. It is treated
    like a schema location hint in XML Schema - an implementation may
    ignore it completely.

    Two modules may import each other. For instance, if module A
    imports module B, then module B may import module A.

3. Variable declarations and definitions

    A variable may be declared or defined using a VarDn in the
    QueryProlog. The syntax of VarDn is as follows:

      VarDn ::=  "define" "global"? "external"? "variable" "$" VarName
                    ("as" SequenceType)? (":=" Expr)?

    A variable may have no forward references to functions or
    variables. Functions and variables imported into a module are
    considered prior to a global variable if they are imported before
    the global variable is defined. A variable may not be used before
    it is defined.

    If the "global" keyword is present, then the variable will be
    imported whenever the module that contains it is imported.

    If the "external" keyword is present, the variable is [external];
    if it is absent, the variable is [internal].

    An [external] variable definition must include only the variable's
    name and optional sequence type, or a static error is raised.
    During dynamic evaluation, an [external] variable must be bound to
    a value in the dynamic context, or an error is raised.

    An [internal] variable definition must include the variable's name,
    optional sequence type, and a required expression, or a static
    error is raised.

    It is a type error, if the value of a variable does not match the
    declared sequence type of the variable.


4. External functions

    An external function definition allows XQuery to call functions
    written in other languages. The syntax of a FunctionDefn is as
    follows:

     FunctionDefn ::= <"define" "function"> "external"? <QName "(">
     ParamList? (")" | (<")" "as"> SequenceType)) EnclosedExpr

    If the "external" keyword is present, the function is [external];
    if it is absent, the function is [internal].

    If a function is [internal], its implementation is given as an
    XQuery expression in the module's implementation. If a function is
    [external], its implementation is given by the query environment.
    XQuery does not specify how external functions are implemented or
    accessed, how actual arguments are passed to external functions, or
    how return values are passed to the query environment - all that is
    implementation defined.

Questions in proposal that need resolution:

In today's telcon, we identified three central questions that need to
be resolved for the modules proposal. Once we resolve these questions,
it will be easy to rewrite the Paulist module accordingly.

Question 1: What is the relationship between the ModuleURI and the
namespace of the functions it contains?

Possible answers:

1.A. There is no relationship. A module is identified by a URI, and
may contain functions in any namespace.

1.B. The module URI is the namespace of functions and global variables
defined in that module. It serves as a default namespace for both
functions and global variables, but the prolog can change these
defaults.

1.C. The module URI is the namespace of functions and global variables
exported by the module. A module may contain functions and global
variables defined in other namespaces or in no namespace, but they are
not exported when the module is imported into another module.


2. Should there an optional LocationURI?

2.A. A module has an optional LocationURI, which provides the location
of a resource. This allows the name of a resource to be decoupled from
its location, while allowing relative or absolute locations to be
specified explicitly.

2.B. A module is identified only by the ModuleURI, which may be
relative or absolute. Catalogs or other similar devices are used to
map the ModuleURI onto a location.

There are two variations on 2.B:

2.B.i: The ModuleURI may be relative.
2.B.ii: The ModuleURI must be absolute.

Relative ModuleURIs are not useful if we choose 2.A.

Jonathan

Note: Michael Kay suggested Option A and Option B. They are defined as:

Option A: (C3, L1)
Option B: (C1, L2)

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Decided to adopt 1B and 2A.

The means by which a query module gains access to the functions defined an an external function library remains to be defined.

Should xmlns only be respected for construction, Xquery expressions but not functions, or also functions?

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Decided to adopt 1B and 2A in proposal for issue #xquery-module-syntax.

What is a query?

According the the algebra: any number of type declarations, function definitions, variable definitions and expressions.

According to XQuery: any number of namespace declarations, function definitions and a unique expression.

These definitions should be coordinated.

The XQuery algebra is a proper subset of XQuery, in particular, the XQuery Core, so however a query is defined in XQuery is the same in the algebra.

Can a namespace prefix be redefined, as in XML?

Text is in Working Draft 2001-11-28 sec 3.

Text is in Working Draft 2001-11-28 sec 3.

Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)

Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)

Acceptance of text in December 2001 published Working Draft.

The syntax currently uses a semicolon as a query module separator. What are the semantics of the query module separator? Is the semicolon the best character for this?

Resolved by XQuery WG to eliminate ';' separator

Does XQuery need a way to specify the encoding of a query? For instance, should the prolog allow statements like the following?

ENCODING utf-16

Decision by: xquery on 2003-01-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0502.html)

The text of a query is in Unicode. Serialization is done in Unicode, but APIs can set other encodings for serialization.

There is no operator to access the typed constant content of an element. In the Algebra, the data() operator does this. Should XQuery do the same?

Cf. Some functions taking node sequences and implicitly map?

Decision by: xpath-tf on 2001-10-23 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0286.html)

Decision by: xquery on 2001-10-31 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Oct/0441.html)

Decision by: xsl on 2001-12-13 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Dec/xxxx.html) It was noted that there are other issues on data() that may lead to further discussions.

Consensus is to define data() on only singleton node and empty sequence. This decision will be reflected in next WD.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

Section 1 - 4th paragraph says the typed-value of an element with complex type is the same as its string-value. This is not currently consistent with the data model. The data model doc says, in section 4.2, "If the element has a complex type, the typed-value is the empty sequence. For an element in a well-formed document with no associated schema, the element's typed-value is the empty sequence."

Ed. Note: Question: I had a note from this, "insert from minutes", but I only see "Need to track "what does data()" return as an issue. Typed value? Something else?" as a response to this issue, and the formulation of issue text for the Data Model. Should this issue be removed from this document? -sb

Decision by: xpath-tf on 2002-03-19 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Mar/0174.html)

Decision by: xquery on 2002-03-20 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0405.html)

Decision by: xsl on 2002-03-28 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Mar/0084.html)

Mary's proposal was adopted.

In particular, we chose option (4a) instead of (4b), because the current semantics applies data() implicitly in the basic conversion rules (e.g., when implementing equality and inequality operators), and therefore (4a) will raise an error if a user attempts to extract the atomic data from an element that has *known* complex type.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft: section 2.1.2.2 of XQuery, 2.1.2.2 of XPath.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

What should the semantics be for == and !== in regards to nodesets and sequences?

This is a Functions & Operators document issue.

It seems like Sequence comparisons should be defined in the Functions & Operators document.

Except for empty sequence comparisons, this is no longer an issue since both operands must be singletons. The empty sequence comparisons are resolved by passing the buck to the specific operator, or returning an empty sequence if both operands are empty sequences.

Subsumed by: #xpath-issue-is-isnot-semantics.

How are collections compared? Note that we need to be able to compare unordered collections as well as ordered collections.

Subsumed by: #xpath-issue-is-isnot-semantics.

Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.

Cf. Should we use is and isnot instead of == and !==.

The '==' operator is already defined in the F&O document and used in XQuery use cases.

Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

The '==' is in the document and usecases.