[main] SQL instead of XQuery

Kurt,

KC> A number of XML database applications that I'm aware of -
KC> the eXist XML database, MarkLogic, DataDirect, not to mention tiny
KC> data delivery companies like Microsoft, Oracle, IBM, etc. -

Avarage user (including which has high education)
brightly uses Insert/Update/Select/Delete.
But NOTHING more! All branded seggestions have SEVERAL bottle necks.
Let's consider on example of Microsoft.

The most narrow place is inserting, which is executed so:
http://msdn2.microsoft.com/en-us/library/aa226534(SQL.80).aspx
1)   inserting xml,
2)   calling function "sp_xml_preparedocument",
3-4) calling function "openxml" and inserting relational
5)   calling function "sp_xml_removedocument"

As PRACTICE shows, it's quite un-available for user.
So these steps should be executed implicitly. I suppose, that
my solution on slides #7-9 (of http://sql50.euro.ru/sql5.11.2.ppt ),
and even mention of tree in request itself (slide #14) is better,
than Microsoft way.

KC> provide an SQL to XML bridge

OK, user will select data without inserting of them! Great!
How Microsoft selects data?
http://msdn2.microsoft.com/en-us/library/aa226553(SQL.80).aspx
We see either under-flight

  select ... join ...                 -- [1]
  for xml;

or flight-over

  select ... for xml auto, elements;  -- [2]
  
  select a1 as tag,                   -- [3]
         a2 as parent,
         a3 as Item!1,
         a4 as Item!1!Attr ...
  for xml explicit;

It's not reasonable to make commercial product un-available for
WIDE CIRCLE of users by [1] collapse of tree into row set;
or by [2] collapse all fields (identical to attributes)
into elements - that is accessible for browser, but not for all
other XML-based languages http://xmlsucks.org/xml_technologies/ ,
or by [3] so bulky constructions, that user can't use them.
So i see again, that #25-27 is better, than Microsoft's way.

Where is possiblitity to specify tree with beforehand unknown
quantity of level (i make this by spec-symbols 'a.b*.c', 'a.b+.c') ?
How can user solve task, assigned as graph (i make this in
slides #41-49) ? By enclosed cycles in PL/SQL ? Instead of one line ?

P.S.
Of course, Microsoft does not worry about permutation and tree
with beforehand unknown quantity of level (#71) !

KC> that makes it possible to integrate
KC> RDBMs content into XQueries through a typically simple XQuery
KC> namespace extension. You still need to write some SQL

Great! XQuery, SQL - how much languages i need!

KC> in general the people writing xqueries are at least modestly SQL
KC> savvy.

And these languages must somehow interact :)
Let's consider task, in which it's necessary to manipulate both
with data from pure relational fields and from xml-attributes [4].
How much users can solve this class of tasks ? No users.
Getting this situation, all data are transfused into xml.
Previous task of Noah Mendelsohn with customer list and
policy documents are demonstrative example of that.

KC> SQL makes joins explicit, XQuery assumes the joins are implicit

SQL+XTree also makes joins implicit.

KC> but beyond that XQuery reflects twenty years of rethinking

And to what has this rethinking brought ?
Not to upgrade of existing language (SQL), but to creating of hybrid,
not usable for users. Nothing to be said, good rethinking.
People was not capable to step over border, separating tuples
and trees.

KC> The two deal with somewhat different domains

SQL+XTree also deals with somewhat different domains.

KC> but the differences are considerably smaller than you might imagine.

Not theoretical position is intersting for me, but what occurs
outside my window (outside my building). Mentioned above [4] says
about nothing ?

Absence of industry of writers (for letters) are not wondered you ?
Maybe population must not know how to write as well
as it doesn't know how to write program ?

===

DT> ---format of storage

DT> You all time are messing query language and format of storage.
DT> I will not agitate to save as relational: please, save as xml
DT> - and use SQL5 to process. Topic is "SQL instead of XQuery" !

nuic>> policy documents can also be stored in the
nuic>> same XML database as the customer list
DT> Any xml-element of policy can be saved as record of table or
DT> as values of xml-field of table.

DT> E.g. SQL5 allows to save automatically xml-elements of top part of tree
DT> (near root) as records, and to save rest, bottom part of tree into
DT> xml-fields of records.
DT> Allows, but not forces. If you want, you can save all tree as xml.

DT> ---query language

nuic>> join in which you select all the policy documents containing XML tags with
nuic>> certain values that match the corresponding values in the customer list,
nuic>> for example.
DT> Even if you have created tree, where records and xml-elements are
DT> alternating (FK can refer from relational to xml, from xml to
DT> relational, from xml to xml !), for example odd level of tree is
DT> record, even level of tree is xml-elements - than also here
DT> you can process tree by SQL5 as united tree !



Dmitry Turin
HTML6     (6. 5.4)  http://html60.euro.ru
SQL5      (5.11.2)  http://sql50.euro.ru
Unicode7  (7. 2.1)  http://unicode70.euro.ru
Computer2 (2. 0.2)  http://computer20.euro.ru