What is a list?

In XQuery, is "list" always synonmyous with "ordered forest"? Are the nodes
in an ordered forest considered siblings (having the same parent) of the
same tree?

I see the term "ordered forest" used for both the entire input data model
instance, as well as what's returned by individual path expressions. At
first, I thought this was an overloaded use of the term, because in the
first case, all the documents and document fragments are indeed siblings
(children of the "implicit root node determined by the environment"),
whereas in the second case, the returned nodes are not necessarily siblings
at all (particularly when selecting attributes or using the UNION operator).
But maybe I shouldn't consider an ordered forest as being one tree
containing child siblings in either case?

Take the following quote from the XQuery draft:

------
For example, LIST(Book) is a shorthand notation for a type defined by
<xsd:element ref="Book" minOccurs="0" maxOccurs="unbounded">, and
LIST(ELEMENT) is a shorthand notation for a type defined by <xsd:any
minOccurs="0" maxOccurs="unbounded">. --
http://www.w3.org/TR/xquery/#section-Datatypes
------

I don't see how lists can be defined this way. My understanding is that this
XSD "particle" is defined as a sequence of *siblings* that make up the
content model, or part of the content model, for a particular element type.
(In this case, the nodes *are* siblings.) I thought that an XQuery list was
more like an XPath node-set, i.e. an abstract collection of nodes which do
not necessarily have the same parent.

Once I try to apply an operator to a list, particularly when using the
parent axis, the disharmony between these models becomes apparent.

Input XML:

<foo>
  <bar/>
  <bar/>
  <bang/>
  <bar>
    <bat>
    <bat/>
    <bang/>
    <bat/>
  </bar>
</foo>


Query:

FOR $b IN /foo/bar UNION /foo/bar/bat
RETURN $b/../bang


I would expect this to return three copies of the first <bang/> element
followed by three copies of the second <bang/> element, because I'm
iterating through the nodes of the source document (which are not all
siblings to each other).

But if the list type treats all members as siblings, then I'm iterating
through a different list of nodes than I originally thought. Instead, I'm
iterating through the siblings of a tree such as the following:

<bar/>
<bar/>
<bar>
  <bat>
  <bat/>
  <bang/>
  <bat/>
</bar>
<bat/>
<bat/>
<bat/>

And the FLWR expression would return empty, because, instead of iterating
through the original nodes, I'm iterating through consecutive siblings, none
of which are <bang/> elements. Also, I'm not sure what ".." would point to
in this instance either, since I'm operating on an XML fragment that
consists of a sequence of elements (perhaps the root of an intermediately
constructed tree containing six child elements?).

Basically, it seems like the comparison of LIST(Book) to <xsd:element
ref="Book" minOccurs="0" maxOccurs="unbounded"> is wrong and misleading.

Maybe this is just an example of the parent operator (..) screwing things
up. If I didn't have that operator, then it wouldn't matter whether the FLWR
expression iterated through the former or the latter of the above two
examples, because the node's context would consist only of its descendants,
and everything below each node stays the same, regardless of its
displacement from the original tree.

However, I'm inclined to believe that this is not what's intended, and that
the minOccurs/maxOccurs comparison is invalid for at least these reasons:

- XQuery does in fact allow you to use the parent axis
- Attributes in a list can't be siblings with elements
- The latter example above would be a pretty weird processing model

It's parenthetically noted in the XQuery draft that "of course, each node
includes its descendant nodes, so the result can be thought of as an ordered
forest." Well, by this "inclusion" terminology, if we have access to the
parent axis, then the node should be thought of as including its parent as
well, and, in actuality, including the entire input data model, since ..
effectively provides traversal to any other part of the tree from any given
node.

In XPath, nodes have defined relationships between each other, but they do
not "include" each other. Another way of putting this is that node-sets
can't be nested. This is also technically the case in XQuery.

Does the terminology of the spec just need to catch up, or am I missing
something?

Thanks,

Evan Lenz

Received on Tuesday, 6 March 2001 21:56:55 UTC