RE: DAV object model expressed as tables

> Anyway, having defined these four tables, the question is 
> whether there's
> some cool SQL operator what would let me define a criteria 
> that would be
> true for this structured value?

I assume you mean "test for equality of the entire
structured value". In a word, no, there is no single 
SQL 92 operator that would let you test for equality 
of the entire structure -- you have to use multiple 
conditions, and multiple joins. Here's one way that would 
work:

    SELECT * 
    FROM 
        (((String AS S1 INNER JOIN Parent AS P1
            ON S1.node = P1.node) INNER JOIN 
            Parent AS P2 ON P1.parent = P2.node)
                INNER JOIN Parent AS P3
                ON P2.parent = P3.node)
        INNER JOIN
        ((String AS S2 INNER JOIN Parent AS Q1
            ON S2.node = Q1.node) INNER JOIN
            Parent AS Q2 ON Q1.parent = Q2.node)
        ON P3.node = Q2.node,
        Label AS L1, Label AS L2, Label AS L3, 
        Label AS M1, Label AS M2
    WHERE
        S1.string = "frog" AND 
            P1.node = L1.node AND L1.label = "C" AND
            P2.node = L2.node AND L2.label = "B" AND
            P3.node = L3.node AND L3.label = "A" AND
            P3.parent = 0 AND
        S2.string = "7" AND
            Q1.node = M1.node AND M1.label = "B" AND
            Q2.node = M2.node AND M2.label = "A"

Note that this would also find all duplicates of the
structure, and any structures with additional information.
The query insists that the structure it finds be a top level 
structure, not a substructure of some other structure.

Note also that I didn't even mention the Child table.

To me, the above is syntax than the following,
because it factors out most of the joins. That makes it
clearer IMHO, and you have control over the types of joins.
(There are multiple types of joins in SQL.) The 
following has all its joins in the WHERE condition
(so all the joins are the default type of join):

    SELECT * 
    FROM 
        String AS S1,
        Parent AS P1, Parent AS P2, Parent as P3,
        String AS S2,
        Parent AS Q1, Parent AS Q2,
        Label AS L1, Label AS L2, Label AS L3, 
        Label AS M1, Label AS M2
    WHERE
        S1.string = "frog" AND 
            P1.node = L1.node AND L1.label = "C" AND
            P2.node = L2.node AND L2.label = "B" AND
            P3.node = L3.node AND L3.label = "A" AND
            P3.parent = 0 AND
        S2.string = "7" AND
            Q1.node = M1.node AND M1.label = "B" AND
            Q2.node = M2.node AND M2.label = "A" AND
        S1.node = P1.node AND
        P1.parent = P2.node AND
        P2.parent = P3.node AND
        S2.node = Q1.node AND
        Q1.parent = Q2.node AND
        P3.node = Q2.node

Now wasn't that really cool?  :)

I'm sending another note on the SQL IN operator.

I'm also sending another note on alternative database 
schemas for this example. The above schema leaves a lot 
of opportunity for improvement, and, more importantly,
provides an opportunity to relate the WebDAV data
model to the SQL data model.


Alan Babich

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: August 28, 1998 11:09 AM
> To: www-webdav-dasl@w3.org
> Subject: DAV object model expressed as tables
> 
> 
> In this message I show how structured values (in the DAV object model)
> could be expressed as relational tables.  I do this in the 
> hope that those
> who are expert in SQL (Alan, that's you) will immediately 
> find a solution
> that draws on SQL.
> 
> Consider the following structured value, showwn first graphically as a
> tree, then as XML as it might be on the wire.  I use the graphical
> representation to emphasize that XML is not the object model
>  
>     1 A                       <A>
>     /\                          <B>
>    /  \                           <C>frog</C>
>   /    \                        </B>
>  2 B   5 B                      <B>7</B>
>  |     |                     </A>
>  3 C   6 "7"
>  |
>  4 "frog"
> 
> One could represent this with four tables:
> 
> child table:    parent table     label table    string table
>   node  child   node  parent     node  label    node  string
>   1     2       1     *          1     A        4     "frog"
>   1     5       2     1          2     B        6     "7"
>   2     3       3     2          3     C
>   3     4       4     3          5     B
>   5     6       5     1
>                 6     5

Received on Tuesday, 8 September 1998 18:34:32 UTC