Re: A good argument for XML

From: <arthernan_at_hotmail.com>
Date: 12 Jul 2005 17:28:05 -0700
Message-ID: <1121214485.431766.55090_at_o13g2000cwo.googlegroups.com>


Richer than, say, SQL-2003 or Date & Darwen's "Tutorial-D"? Note that these also allow you to define hierarchical data-structures (although not as unrestricted as XQuery would) but are easier to optimize than XQuery and are therefore much more likely to give you scalable solutions.

  • Jan Hidders

OK I had to do some reading before I answered. And I looked at Rel's documentation which claims to be the most thorought implementation ot Tutorial D. I also read

SQL:2003 Has Been Published by Andrew Eisenberg, Krishna Kulkarni, Jim Melton, Jan-Eike Michels, Fred Zemke
http://www.sigmod.org/record/issues/0403/index.html#standards

which in turned referred to

SQL/XML is making good progress by Andrew Eisenberg http://portal.acm.org/citation.cfm?id=565141&coll=portal&dl=ACM

I also have read about XQuery.

I did not find anything about Tutorial D that produced a hierarchical output syntactically. Maybe I am looking on the wrong place.

SQL/XML looks very similar to XQuery. Where XQuery looks interesting for querying hierarchical data to produce hierarchical data. Databases are mostly relational and the syntax of XQuery for this propose seems overly redundant. Here is an extract of "SQL/XML is making good progress"

<highemps>

    { for $e in table ("Sample_db",

                       "Andrew",
			     "*password*",
			     "HR.ADMIN.EMPLOYEE"
                       ) /EMPLOYEE/row
      where $e/SALARY > 40000
      return
          <emp>
             {  $e/FIRSTNAME, $e/LASTNAME }
          </emp>

    }
</highemps>

the syntax: "for $e in table where return"

Is very reminiscent of SQL but there is so much "extra" stuff here. The parameters for the TABLE function are strings, why. Shouldn't there be an easier way. "/EMPLOYEE/row" is again something that does not add to the operation being done. I could go on and on.

I do not trying to blast the SQL/XML committee. They are proposing a solution. In my thinking they are just too focused on the XML aspect rather than the more broad Hierarchical output requirement.

To illustrate; the statement "select lastname,firstname from employee" uses the select clause to specify column names, and positions. The output is clearly tabular whether stored as text, comma separated or even XML. I

I could only imagine having to write

for $e in table employee

      where $e/SALARY > 40000
      return '"'||$e/FIRSTNAME||'","'||$e/LASTNAME||'"'

Just to get a tabular output. As defined on some SQL/CSV standard.

I am not a database theorist. But I do use databases on a daily basis. And I will read "any" reference given to me.

Arturo Hernandez Received on Wed Jul 13 2005 - 02:28:05 CEST

Original text of this message