Re: Two comments on the XML Query Data Model.

We apologize for the delay in responding to your questions and 
will do our best to be more prompt in the future.

> Date: Thu, 28 Sep 2000 13:20:44 -0700 (PDT)
> From: Murali Mani <mani@CS.UCLA.EDU>
>
> Hi,
> 
> I was reading the XML Query Data Model draft, and I had two possible
> comments/questions. I would appreciate i could get the opinions of the
> Query WG members on these.
> 
> Thanks - Murali.
> 
> ===================
> 
> 1. I believe one of the parallels to a relational table definition and
> multiple rows in the table in the XML world is define one schema and have
> multiple documents for it. From my glancing at the data model draft, I
> could not find any mention of such a requirement. Is it not suitable to
> define an XML repository/database as <schema, setOfDocs> pairs?

Yes, that is a perfectly suitable definition, although it does not
correspond directly to the PSV Infoset, which is the basis
for the XML Query Data Model.  An instance of the PSV Infoset 
is a document annotated with the schema information by which
it was validated.  The XML Query Data Model is based on this input.

It might be appropriate, however, for an *implementation* of
the XML Query Data Model to represent an XML database as a 
schema, document-set pair. 

> 
> 2. The Query WG relies on obtaining an ordered list of trees (also called
> hedge, sometimes also called forest) for the result of a Path expression.
> This is not provided by XPath which, I believe, defines a node set (one
> of the four possible results of an XPath Expression) as an unordered set
> of trees. Does not this additional requirement for the Query purposes
> require more definitions in the data model? What I think is required is
> that you define an order for nodes that can be returned by one path
> expression.

You are correct: the Query Data Model supports ordered lists (forests)
of trees, and XPath expressions compute node sets, which, when
necessary, are sorted by a total document order.  It is somewhat
cumbersome
to define XPath's semantics in terms of ordered lists.
Even in the absence of this incompatibility, support
for unordered collections (e.g., bags and sets) of trees
are required by the XML Query use cases.  Therefore, unordered
collections of trees will be added to the XML Query Data Model
and will be supported by the XML Query Algebra.  Unordered collections,
however, will not appear in the first public working draft
of the Algebra but will appear in a subsequent draft.  Given unordered
collections, it is possible to define XPath semantics correctly
and simply.

> 
> A typical example of the above scenario is in traversal of links, for
> example, you can have a book element which has author as children, and
> also an IDREFS attribute called authors which points to person.
> I believe such a path expression is valid -
> book/(author | @authors -> person)
> Now does this not require an order specification between child elements
> and elements reachable through links? The reason is a user might expect
> the same ordered result for the above expression as for the following
> expression -
> book (@author -> person | author)
> Note that the above is possible even without an OR operator in the query.
> 

A minor point: the above syntax is from Quilt, not XPath.
XPath uses the id() function to dereference IDREF(S) values.
As you note, the two expressions above should be equivalent.
XPath does *not* require an order specification between child
elements and dereferenced IDREF attributes, because all nodes
are always sorted by *document* order.  The assumption is that
a total document order exists on nodes, and that order may be
implementation
dependent.
-- 
Mary Fernandez                    AT&T Labs - Research          
Principal Technical Staff Member  180 Park Ave., Bldg 103, E243 
mff@research.att.com		  Florham Park, NJ 07932-0971   
http://www.research.att.com/~mff  973-360-8679 FAX: 973-360-8187

Received on Thursday, 14 December 2000 10:11:05 UTC