A.1.1 Grammar Notes

grammar-note: parens

A look-ahead of one character is required to distinguish function patterns from a QName or keyword followed by a Pragma, MUExtension or Comment. For example: address (: this may be empty :) may be mistaken for a call to a function named "address" unless this lookahead is employed. Another example is for (: whom the bell :) $tolls = 3 return $tolls , where the keyword "for" must not be mistaken for a function name.

grammar-note: lt

A tokenizer must be aware of the context in which the "<" pattern appears, in order to distinguish the "<" comparison operator from the "<" tag open symbol. The "<" comparison operator can not occur in the same places as a "<" tag open pattern.

grammar-note: validate

The ValidateExpr in the exposition, which does not use the "< ... >" token grouping, presents the production in a much simplified, and understandable, form. The ValidateExpr presented in the appendix is technically correct, but structurally hard to understand, because of limitations of the "< ... >" token grouping.

grammar-note: leading-lone-slash

The "/" presents an issue because it occurs either as a stand alone unit or as a leading prefix that expects a pattern to follow such as a QName or "*". Both of these patterns also may occur as patterns which are recognized in contexts where operators may occur. Thus, expressions such as "/ * 5" can easily be confused with the path expression "/*". Therefore, a stand-alone slash on the right hand side of an operator, will need to be parenthesized in order to stand alone, as in "(/) * 5". "5 * /", on the other hand, is legal syntax.

grammar-note: comments

Expression comments are allowed inside expressions everywhere that ignorable whitespace is allowed. Note that expression comments are not allowed in constructor content.

Comments can nest within each other, as long as all "(:" and ":)" patterns are balanced, no matter where they occur within the outer comment.

Note:

Lexical analysis may typically handle nested comments by incrementing a counter for each "(:" pattern, and decrementing the counter for each ":)" pattern. The comment does not terminate until the counter is back to zero.

Following are some illustrative examples:

• for (: set up loop :) $i in $x return $i will parse correctly, ignoring the comment.

• 5 instance (: strange place for a comment :) of xs:integer will also parse correctly, ignoring the comment.

• <eg (: an example:)> $i//title </eg> will cause a syntax error.

• <eg> (: an example:) </eg> will parse correctly, but characters inside the element is element content, and not an expression comment.

See Comments , Pragmas and Extensions for further information and examples.

grammar-note: xml-version

An implementation's choice (see to support the [XML 1.0] and [XML Names], or [XML 1.1] and [XML Names 1.1] lexical specification determines the external document from which to obtain the definition for this production. For convenience, XML 1.0 references are always used. In some cases, the XML 1.0 and XML 1.1 definitions may be exactly the same. Also please note that these external productions follow the whitespace rules of their respective specifications, and not the rules of this specification, in particular 2.6.5 XML and Names 1.1 Feature ) to support the [XML 1.0] and [XML Names], or [XML 1.1] and [XML Names 1.1] lexical specification determines the external document from which to obtain the definition for this production. For convenience, XML 1.0 references are always used. In some cases, the XML 1.0 and XML 1.1 definitions may be exactly the same. Also please note that these external productions follow the whitespace rules of their respective specifications, and not the rules of this specification, in particular A.2.2.1 Default Whitespace Handling . Thus prefix : localname is not a valid QName for purposes of this specification, just as it is not permitted in a textual XML document. Also, comments are not permissible on either side of the colon.

grammar-note: reserved-function-names

Some unprefixed function names may be confused with expression syntax by the parser. For instance, if(foo) could either be a function name invocation or an incomplete IfExpr. Therefore it is not legal syntax for a user to invoke functions with these names. See A.3 Reserved Function Names for a list of these names.

grammar-note: occurrence-indicators

The '+' and '*' Kleene operators are tightly bound to the SequenceType expression, and have higher precedence than other uses of these symbols. Any occurrence of '+' and '*', as well as '?', following a sequence type is assumed to be an occurrence indicator. Thus, 4 treat as item() + - 5 is interpreted as (4 treat as item()+) - 5 , so that the '+' would be an occurrence operator, and the '-' in this case would be a subtraction operator. To have this interpreted as an addition operator of a negative number, the form (4 treat as item()) + -5 would have to be used, so that the SequenceType expression is bounded by a parenthisis.

A.2.1 Terminal Types

The entire set of terminals in XQuery 1.0 may be divided into two major classes, those that can act as token delimiters, and those that can not.

[Definition: A delimiting terminal may delimit adjacent non-delimiting terminals.] The following is the list of delimiting terminals:

, "<?", "?>", "::", "*", "$", "?", ")", "(", "{", ":", "/", "//", "=", "!=", "<=", "<<", ">=", ">>", ":=", "<", ">", "-", "+", "|", "@", "[", "]", ",", ";", "%%%", """, ".", "..", "<![CDATA[", "]]>", PredefinedEntityRef, CharRef, "/>", "</", "{{", "}}", EscapeQuot, EscapeApos, "'", Pragma, "(::", "::)", comment">Comment, "(:", ":)", "<!--", "-->", S, "}"

[Definition: Non-delimiting terminals generally start and end with alphabetic characters or digits. Adjacent non-delimiting terminals must be delimited by a delimiting terminal.] The following is the list of non-delimiting terminals:

DecimalLiteral, DoubleLiteral, StringLiteral, "xquery", "version", "encoding", "at", "module", "namespace", "child", "descendant", "parent", "attribute", "self", "descendant-or-self", "ancestor", "following-sibling", "preceding-sibling", "following", "preceding", "ancestor-or-self", "declare", "function", "option", "ordering", "ordered", "unordered", "default", "order", "external", "or", "and", "div", "idiv", "mod", "in", ValidationMode, "construction", "satisfies", "return", "then", "else", "boundary-space", "base-uri", "preserve", "strip", "copy-namespaces", "no-preserve", "inherit-namespaces", "yes"", "no-inherit", "to", "where", "collation", "intersect", "union", "external", "or", "and", "div", "idiv", "mod"except", "as", "case", "instance", "of", "castable", "item", "element", "schema-element", "schema-attribute", "processing-instruction", "comment", "text", "empty", "import", "schema", "is", "eq", "ne", "gt", "ge", "lt", "le", "some", "every", "for", "let", "cast", "treat", "validate", ValidationModedigits">Digits, "construction", "satisfies", "return", "then", "else", "xmlspace", "base-uri", "preserve"document-node", "document", "node", "if", "typeswitch", "by", "strip", "to", "where", "collation", "intersect", "union", "except"stable", "as", "case", "instance", "of", "castable", "item", "element", "schema-element", "schema-attribute", "processing-instruction", "comment", "text", "empty", "import", "schema", "is", "eq", "ne", "gt", "ge", "lt"cending", "descending", "greatest", "le", "some", "every", "for", "let", "cast", "treat"ast", "validate"variable", Digits, "document-node", "document", "node", "if", "typeswitch", "by", "stable", "ascending", "descending", "greatest", "least", "variable", ExtensionContents, commentcontents">CommentContents, "pragma", "extension", QName, NCName

A.2.2 Whitespace Rules

A.2.3 Comments , Pragmas and Extensions

Pragmas and MUExtensions may be used anywhere that ignorable whitespace is allowed. Within a Pragma or MUExtension, the extension content may consist of any sequence of characters that does not include the sequence "::)". Pragmas, and MUExtensions are not allowed to nest. Comments are allowed to nest, though the content of a comment must have balanced comment delimiters without regard to structure. Some illustrative examples:

• (: is this a comment? ::) is a legal Comment.

• (: can I comment out a (:: pragma foo ::) like this? :) is a legal Comment. The inner pragma is seen as a nested comment in this case.

• (: is this a comment? ::) or an error? :) must produce a syntax error. Any unbalanced nesting of "(:" and ":)" will result in an error.

• (: what about a partial (:: pragma? :) must produce a syntax error. Any unbalanced nesting of "(:" and ":)" will result in an error.

• (:: pragma foo with a comment (: is this ok? :) or not ::) is a legal Pragma. The inner "comment" is seen as part of the extension content in this case.

• (:: pragma foo with a comment (: is this a comment? ::) or an error? :) ::) is a syntax error. "::)" patterns are not allowed inside pragma's and extensions.

• (:: pragma foo with a comment (: what about a partial (:: pragma? :) ::) is a legal Pragma. The inner "comment" and "(::" are seen as part of the extension content in this case.

• (: commenting out a (: comment :) may be confusing, but often helpful :) is a legal Comment, since balanced nesting of comments is allowed.

• "this is just a string :)" is a legal expression. However, (: "this is just a string :)" :) will cause a syntax error. Likewise, "this is another string (:" is a legal expression, but (: "this is another string (:" :) will cause a syntax error. It is a limitation of nested comments that literal content can cause unbalanced nesting of comments.