- From: Michael Dyck <MichaelDyck@home.com>
- Date: Fri, 13 Apr 2001 15:16:40 -0700
- To: www-xml-query-comments@w3.org
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