- 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