Comments on XQuery appendices

More Comments on
XQuery: A Query Language for XML
W3C Working Draft  15 February 2001

----------------------------------------------------------------------------
A. References

    Under "Requirements", the reference for "Algebra" is missing its header.

    Many of the hyperlinks are not separated from the preceding word.

----------------------------------------------------------------------------
B. XQuery Grammar

SimpleDatatype
'@' QName
    This alternative is not discussed in the text.

FlwrExpr
    I think 
        FlwrExpr ::= (ForClause | LetClause | WhereClause)+ ReturnClause
    would be an improvement.

    What I'd *really* like (for various reasons) would be something like:

        FlwrExpr  ::= ForExpr | LetExpr | WhereExpr
        ForExpr   ::= 'FOR' Variable 'IN' Expr 'DO' Expr
        LetExpr   ::= 'LET' Variable ':=' Expr 'DO' Expr
        WhereExpr ::= 'WHERE' Expr 'DO' Expr

    Note that this is pretty much what the XML Query Algebra has. (Actually,
    I'd prefer ':' over 'DO', but I think the colon would create lexical
    problems.)

NodeGenerator
'@' nameTest ( '->' NameTest )?
    This is fairly restrictive. For instance, say I only wanted to
    dereference "foo" attributes whose values started with "H". I'd write

        .../@foo[ starts-with(.,"H") ]->*

    but this violates the given syntax for '->'. Or say I was only
    interested in "foo" attributes that pointed to <chapter>s.  I'd write

        .../@foo[ .->chapter ]

    but that isn't valid either. Or say I wanted to dereference the "foo"
    and/or the "bar" attributes. Assuming XPath 2.0 allows unions in a
    location step (and that XQuery adopts it too), I'd write

        .../(@foo|@bar)->*

    which also isn't valid.  You could modify the grammar to allow all these
    cases, but it would be messy and ad hoc.

    In XPath, there's only two ways to "go" from one node to another: via an
    axis, or via a function. You've added a third way, but its syntactic
    usability is more restricted than even function-calls, much less axes.
    I think things would be easier (syntacically and semantically) if you
    defined the dereferencing operation as an axis.  You could say that the
    'deref' axis contains the element referenced by the string-value of the
    context node. Then my examples would be:

        .../@foo[ starts-with(.,"H") ]/deref::*

        .../@foo[ deref::chapter ]

        .../(@foo|@bar)/deref::*

    You could then define the easier-to-read '->' as an abbreviation of
    "deref::" (exactly parallel to the way that '@' is an abbreviation of
    "attribute::"), leading to:

        .../@foo[ starts-with(.,"H") ]/->*

        .../@foo[ ->chapter ]

        .../(@foo|@bar)/->*

    For comparison with the current syntax, Q4 would be

        /emp[rating = "Poor"]/@mgr/->emp/@mgr/->emp/name

    That is, the paths/queries would look very similar to what you're
    currently considering, but the underlying syntax and semantics would be
    much more consistent with XPath (and thus the XPath subset of XQuery).

StartTag ::=  '<' TagName AttributeList? '>'
AttributeList ::= (Attributename '=' Expr)*
    The '?' on AttributeList is unnecessary, since the '*' in the production
    for AttributeList ensures that it derives the null string.

LogicalOp
    What's the difference between 'UNION' and '|' ?

----------------------------------------------------------------------------
E. XQuery Semantics

E.1 Notations
"[[ E ]]_c ==> e     Given the context c, ..."
    Apparently, "c" is either "l" or "type", but you don't say what these
    mean or how they arise. Moreover, using the word "context" is confusing,
    since it has nothing to do with XPath's concept of evaluation context.

----------------------------------------
E.2.1 Path expressions

para 1
"do not currently support all the axis of XPath"
    Change "axis" to "axes".

"Axes of Xpath"
    Change "Xpath" to "XPath".

para 2
"XPath abreviations"
    Change "abreviations" to "abbreviations".

"for instance, name is already in the form ./name, ..."
    These two examples are not what XPath would consider "resolving
    abbreviations". That is, "name" is not an abbreviation of "./name", as
    far as XPath is concerned; "name" (in this example) is an abbreviation
    of "child::name".

----------------------------------------
E.2.1.1 Current node

para 1
"called dot"
    Maybe put "dot" within <CODE> (twice in the para).

----------------------------------------
E.2.1.2 Root node

para 1
"special algebra"
    Change "algebra" to "Algebra"?

"function root()"
    Put "root()" in <CODE>?

"the preamble section"
    This use of "preamble" (a set of XML Query Algebra functions) conflicts
    with the uses in Section 2.10 (point 3), Appendix E (para 3), and
    E.2.2.1, meaning a set of schema, namespace and function declarations in
    the XQuery language.

----------------------------------------
E.2.1.3 Simple Navigation

"for a being: element names, attribute names"
    Change to "whether <CODE>a</CODE> is an element name or attribute name"

"with name a"
    Put "a" in <CODE>.

"XQuer"
    Change to "XQuery".

----------------------------------------
E.2.1.4 Recursive Navigation

"function called descendant"
    Put "descendant" in <CODE>.

"with the algebra"
    Capitalize "algebra"?

----------------------------------------
E.2.1.5 Access to ...

"are in the algebra"
    Capitalize "algebra"?

"[[E]]/pi()"
    Change "pi" to "processing_instruction".

"[[ E/NODE() ]] ==> [[E]]/node()"
    Maybe the RHS should just be "[[E]]". (That is, NODE() doesn't project
    anything away.)

"[[E]]/value()"
    According to the Algebra spec, value() "returns the value of a comment
    or processing instruction". Perhaps you mean "data()". On the other
    hand, that isn't quite right. The problem is that XML Query Algebra
    doesn't have anything corresponding to text nodes per se.

----------------------------------------
E.2.1.7 Predicates

"the dot variable"
    Put "dot" in <CODE>.

----------------------------------------
E.2.1.8 Parent

"the corresponding parent built-in function"
    Put "parent" in <CODE>.

"in the algebra"
    Capitalize "algebra"?

----------------------------------------
E.2.2.1 Local and qualified names

"corresponding statements"
    The Algebra doesn't have 'statements'.
    Change to "constructs" or "expressions"?

----------------------------------------
E.2.2.2 Element and attribute constructors

~(v)
    I don't think the XML Query Algebra defines this notation.

"the Ei's might return attributes"
    It's not clear that "Ei's" is the plural of Ei', not of Ei.
    Maybe change to "any Ei' might return attributes".

"in which case the algebra"
    Capitalize "algebra"?

"should append then"
    Change "then" to "them".

"explicitely"
    Change to "explicitly".

----------------------------------------
E.2.2.3 Comments and PI's constructors

"pi([[E]])"
    Change "pi" to "processing_instruction".
    Also, the function takes two parameters in both XQuery and the Algebra.

----------------------------------------
E.2.3.1 F to for, L to let, W to where, R to do

    What an odd section title. How about just "For, Let, Where, Return"?

$vk' IN Ek'
    Change "IN" to ":=".

"for vk' in [[Ek']] do"
    Change "for" to "let".
    Change "in" to "=".

----------------------------------------
E.2.3.2 Sort by

"criterias"
    Change to "criteria".

"which is the only currently available in"
    There's a noun missing between "only" and "currently": "criteria"?

----------------------------------------
E.2.4.2 Predicate operators

para 2
"Cf. [xquery-xpath-coercions]"
    This should be in parentheses.

Mapping for <= thru !=
    Insert "do v1".

----------------------------------------
E.2.4.3 Arithmetic operators

"Here is a few"
    Change "is" to "are".

----------------------------------------
E.2.4.4 Collection operators

    This section doesn't define the | operator.

Definition of list construction and concatenation:
    These don't handle the flattening described in section 2.8.

Definition of UNION:
    Change "distinct" to "distinct_node".
    Or else define "distinct" in E.3.4.

"the subset of the element in the first expression"
"after one of the element in the second expression"
    Change each "element" to "elements".

Definition of BEFORE:
"v2 > v1"
    "v1 < v2" would be better.

----------------------------------------
E.2.7 Function Calls and Declarations

Definition of function call:
    This doesn't handle the funky rules (especially point 4) given in
    section 2.9.

"Notable the FILTER function"
    Change "FILTER" to "<CODE>filter</CODE>"?

----------------------------------------
E.2.8 Existential and Universal Quantifiers

para 1
"mapped to existential predicate"
    Change "predicate" to "quantification"?

----------------------------------------
E.2.9 Variables

"(* variables *)"
    Not a useful comment.

----------------------------------------
E.2.10 Operations on Types

"operation on the types"
    Delete "the".

----------------------------------------
E.3.1 Mapping of type declarations

mappings
    It would be nice if the "==>" were aligned.
    Ditto the comments, except that all but the last are fairly useless.

----------------------------------------
E.3.2 Mapping of namespace declarations

para 1
"Namespace declarations in XQuery are mapped to global variables in the
Algebra."
    So, for instance, in

        NAMESPACE foo = "www.example.com/names"
        LET $foo := 1
        RETURN <foo:num>$foo</foo:num>

    both the namespace prefix and the variable name would be mapped to
    variable "foo" in the Algebra. So the inner one would hide the outer,
    and "foo:num" would fail type-checking.

"the uri function"
    Put "uri" in <CODE>?

----------------------------------------
E.3.3 Mapping of function declarations

"FUNCTION f(T1 v1, ..., Tn vn) ..."
    Change "v1" and "vn" to "$v1" and "$vn".

----------------------------------------
E.3.4 Predefined functions

para 1
"functions, which are not"
    Delete the comma and change "which" to "that".

declaration of 'descendant' function
    Actually, "descendant_or_self" would be a more appropriate name.

    Change "children(v)" to "descendant(children(v))".

filter
"The following algebra functions"
    Capitalize "algebra"?

"implement the corresponding XQuery filter function"
    Don't need "corresponding".
    Put "filter" in <CODE>?

"this definition lose all type information"
    Change "lose" to "loses".

"where v == y do v"
    Change "y" to "x".

----------------------------------------------------------------------------
H. XQuery Issues List

----------------------------------------
Issue 5: Function Definition

"Should all MSL symbol spaces be represented?"
    This is the first of three mentions of MSL. There should be a reference
    to it in Appendix A.

----------------------------------------
Issue 9: Separation of clauses in FLWR

"This functionality [WHERE expr1 RETURN expr2] 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."
    So why have WhereClauses at all then?

    I think the main justification for WhereClauses arises when expr2 is
    large and complicated. If you had to use an IF expression, it would be
    kind of annoying to have to tack on the "ELSE []" after a big expr2.
    (I suspect that people would forget.) If you're reading the query, a
    WhereClause is nice because once you've understood the condition
    (expr1), you can put that "in the background", knowing that you won't
    be called upon to consider its negation.

    (As I said in my comments on Appendix B, I think WhereClauses should be
    allowed to interleave with ForClauses and LetClauses, in which case a
    "stand-alone" WhereClause just falls out of the grammar.)

"However, making the ELSE clause optional might be a slight improvement."
    NO! That would create a "dangling ELSE" problem. That is, in
        IF a THEN b IF c THEN d ELSE e
    it's ambiguous whether the ELSE belongs to the inner or outer IF.

    On the other hand, if there were an required ENDIF or FI keyword, you
    could easily make the ELSE clause optional. But I suspect that people
    would forget to put in the ENDIF just as easily as they'd forget to put
    in the "ELSE []".

----------------------------------------
Issue 10: Alignment of Syntax

"Should the syntaxes of XQuery and the XML Query Algebra be more closely
aligned?"
    Yes, they should. In fact, I think they should be merged. (Although I'm
    open to being convinced otherwise.)

----------------------------------------
Issue 11: Alternative syntax for element construction 

"square brackets are used in XQuery to enclose predicates"
    And list constructions.

----------------------------------------
Issue 12: Fusion

"Consider adding a fusion operator to XQuery."
    What would it do?

----------------------------------------
Issue 23: What is a Query

"According the"
    Change "the" to "to".

"the algebra"
    Capitalize "algebra"?

"a unique expression"
    Change "unique" to "single"? Its uniqueness is not relevant.

----------------------------------------
Issue 26: Identity-based equality operator

"Do we need an identity-based equality operator? Please justify your answer
with sample queries."
    How about a query that returns all the siblings of $x? The expression
        $x/../*[. != $x]
    has almost the right semantics, but it will exclude any siblings that
    have the same string-value as $x.

    How about a function that does something different if its parameter $x
    is the root node?
        IF $x = / THEN ... ELSE ...
    In many documents, the condition (using string-value semantics) will
    also be true of the document element, which was not the intent.

    Note that the BEFORE operator allows you to define identity-based
    equality (between elements that belong to the same data model instance):

        FUNCTION is( ELEMENT $a, ELEMENT $b ) RETURNS xsd:boolean
        { empty( $a BEFORE $b ) AND empty( $b BEFORE $a ) }

    Or maybe

        FUNCTION is( ELEMENT $a, ELEMENT $b ) RETURNS xsd:boolean
        { count( $a UNION $b ) == 1 }

    But it would be annoying to have to define and use either of these
    functions.

----------------------------------------
Issue 31: Function Libraries

"It must be possible to specify either that (1) local definitions replace
the imported definitions, or (2) imported definitions replace the local
ones."
    You could achieve this simply by order, where the later declaration
    takes precedence.
    To obtain case (1), put the local defns after the IMPORT statement.
    To obtain case (2), put the IMPORT statement after the local defns.
    (I suspect that people won't want (2) very often.)

----------------------------------------
Issue 35: Escape to ABQL

"Is there a need to be able to escape to ABQL?'
    What is ABQL? Could you supply a reference?
    Issue 52 suggests that it's an XML representation for queries.

----------------------------------------
Issue 38: Attribute Constructor Function

"ELSE []f"
    Delete the "f".

"the first parameter of attribute"
    Put "attribute" in <CODE>.

----------------------------------------
Issue 45: Typing of Filter

"The current mapping of filter"
"another approach to filter"
    Put "filter" in <CODE>, twice.

----------------------------------------
Issue 50: Embedding XQuery in XML

"Do we need a way to escape from XML to XQuery syntax?"
    Don't we already have one? e.g.
        <xquery>
        <![CDATA[
            document("zoo.xml")//figure[caption = "Tree Frogs"]
        ]]>
        </xquery>

----------------------------------------
Issue 51: Naive Implementation Strategy

"a specific implementation language such as XPath"
    I don't think you could use XPath as an implementation language.

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

-Michael Dyck

Received on Friday, 13 April 2001 18:17:26 UTC