A Markup Database Interface; Borrowing from Groves - Mailing list pgsql-hackers

From Clark C. Evans
Subject A Markup Database Interface; Borrowing from Groves
Date
Msg-id Pine.LNX.4.10.10001082200590.3652-100000@cauchy.clarkevans.com
Whole thread Raw
In response to LIBPQ patches ...  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-hackers
Hello all.  I wanted to throw up an idea for a
XML interface to PostgreSQL. 

The underlying information model for SGML documents
is called the "groves" model.  The model's primary
prupose is to handle multiple content hierarchites
within a single network; as this is the primary 
problem with multimedia hypertext markup (HyTime).
Anyway, what is interesting is that the core of the
groves model seems to be the following seemingly
simple production:
 node :=  character | map( string, list(node) )

It is an alternation between a map (unordered 
set) and a list (ordered bag).  Anyway, the discovery
made me sit back in my chair and go hmmmmmm. As it 
seems to me; this model is the essence of a multi-level 
result set, and could point towards a rather natural
mapping of a multi-hierarchy result set onto a tag
based markup language like XML.

For starters, here is a row...
 row-node := map (string, list(characters))

For example, here is an order, and two order-line rows:
 order-row-node  :=  { id       = '345'                     , buyer    = 'Clark Evans'                     }
 order-line-row  :=  { order-id = '345'                     , product  = 'Bag of rice'                       , quantity
='1'                     }
 
 order-line-row  :=  { order-id = '345'                     , product  = 'Tofo'                     , quantity = '3'

And here, is a table:
 relation-node   := map('relation-name',list(row-node))
 line-relation   := { order-line =                       [                        { order-id = '345'
   , product  = 'Bag of rice'                        , quantity = '1'                        }                      ,
                     ...                      ,                        { order-id = '345'                        ,
product = 'Tofo'                        , quantity = '1'                        }                      ]
     }
 

Here is the origonal production again:
 node :=  character | map( string, list(node) )      

It could then be used to return a nested
result set like:
  SELECT *     FROM ORDER    WHERE ID = '345'       with this sub-query nested...
   SELECT PRODUCT, QUANTITY      FROM ORDER_LINE     WHERE ORDER_ID = ID;
 my-order  =:  { id = '345'               , buyer = 'Clark Evans'               , lines =                      [
               { order-id = '345'                        , product = 'Bag of rice' }                        , quantity
='1'                        }                      ,                        { order-id = '345'                        ,
product= 'Tofo'                        , quantity = '3'                        }                      ]
 }
 

Here is a mapping to a simple markup language 
(http://www.egroups.com/list/sml-dev/info.html)

<order> <id>345</id> <buyer>Clark Evans</buyer> <order-line-list>    <order-line>      <product>Bag of rice</product>
  <quantity>1</quantity>    </order-line>    <order-line>      <product>Tofo</product>      <quantity>3</quantity>
</order-line></order-line-list>
 
</order>

So, if you notice the even levels are maps, 
and the odd levels are lists.  Kinda cool.

Of course, you can shorten it with attribute notation...

<order id="345" buyer="Clark Evans"> <order-line product="Bag of rice" quantity="1" /> <order-line product="Tofo"
quantity="3" />
 
</order>
 (The syntax is more brief, but it only   allows for one list per map)

Anyway, this could allow for some nice automated
conversions in between a database and SML/XML/SGML.

Indeed, I was thinking that a binary version of
of the former syntax would make for a great 
interface into/outof the database.  Add a simple
text/binary adapter and PostgreSQL would be
XML ready... without the need for any particular
mapping tool.

Best,

Clark
















pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Table locking ...
Next
From: Tom Lane
Date:
Subject: Regress tests reveal *serious* psql bug