Re: XQuery question

Costin Cozianu wrote:

[transitive relations]

>
> SQL '99 it's called WITH RECURSIVE. IBM db2 decided that recursive is
> superfluous and didn't implement the full options (which are probably
> more powerfuil than you need for transitive closure)
>
> Here's a DB2 Example:
>
> CREATE TABLE Rel (ID integer, Parent integer );
>
> WITH MyView ( ID Integer, Ancestor integer)
> AS ( SELECT ID , Parent as Ancestor FROM Rel
> UNION ALL
> SELECT r1.ID, r2.Parent AS Ancestor
> FROM Myview r1, Rel r2
> WHERE r1.Parent= r2.ID )
> SELECT * from MyView
>
> As you can see MyView is joined recursively with otsel;f in its
> definition so that we get the transitive closure.

Now, just tell me in which way this is *declarative*, and why SQL is less complex than XML query languages...<g>

>>> But in order to do a fair and unbiased comparison I'd like to know if
>>> XQuery is relationally complete (including the transitive closure of a
>>> binary relation).
>>

Whether XQuery is relationally complete or not is of no relevance, since it is not intended to be so, as the underlying data is not relational, it is tree-shaped.

>>
>> But I don't mean to brush off your question. I actually took a stab at
>> defining the relational primitives you cite. I didn't have much of a
>> problem; cartesian product, intersection, union, set difference (called
>> except), projection and selection are implemented directly in terms of
>> sequences, which resemble sets well enough given certain constraints. I
>> think you would appreciate how easy it is to understand XQuery FLOWR
>> (for,
>> let, order by, where, return) expressions given your SQL background.
>
>
> No, I don't really appreciate that :) Although the rule of XQuery are
> quite simple and intuitive, the fact that I have to "encode" my data
> model by hanging all data items in a chrsitmas tree, makes me have
> very little appreciation if any to XML as a data model (you call that
> XML "infoset" or something, I beleive).

I prefer encoding my data model as a tree in my data model than encoding it in completely ridiculous SQL queries (see above). If the data is inherently graph-structured it is much more intuitive to represent it graph structured and provide appropriate query languages for it (note: I don't think XQuery is appropriate, but this is not the fault of the XML data model).

> Plus I don't really see how mixing orthogonal concerns like logical
> data structure and physical data encoding (representaition, viz. the
> bloody tags) is going to help me in any way shape or form. Dijkstra
> told us we can do better decades ago, viz. separtion of concerns, and
> Codd was of the same opinion.

In fact, XML is all about "logical data structure" and none about physical encoding. XML is merely a form of tree structured data representation which is IMO rather intuitive for the user. How the data is stored is a completely different matter. It could be an XML view on a relational database. It could also be an XML view on an XML document. And it can be a mixture of both (i.e. combined XML view onto multiple, heterogeneous databases).

> This leads in my opinion to way unnecessary complexity.

As for unnecessary complexity, I'd like again to refer to your SQL example above.

>> As to transitive closure, XQuery can do these with no problem, as I have
>> tried to illustrate elsewhere in this thread. But here _I_ need a
>> reference.
>> What is the definition of transitive closure in relational terms?
>
>
> Transitive closure is not a relational term, I knew that from my first
> introductory course in algebra, before I knew what a dataabse was.

What else, if not a relational term? Transitive closure is all about relations...:-) The fact that it does not exist in current SQL implementations does not exclude it from relational terms...

-- 
Sebastian

| Dipl.-Inform. Sebastian Schaffert                    LFE Programmier-/
| schaffert_at_informatik.uni-muenchen.de             Modellierungssprachen
| LMU München - Institut für Informatik - Zimmer C8 - Tel: 089/2180-9781

PGP Key fingerprint =  
       13 1D 2E 4F 20 3E C9 1F  4C 57 52 87 8A 80 48 4D  F5 E9 97 EC