| The biggest problem with the Oracle white paper is that it assumes
| that another quirky bolt-on is needed, such as their previous TREE
| construct, instead of showing how basic SQL can do the job in a more
| general and flexible fashion.
Not sure what "quirky bolt-on" you are referring to, nor which TREE
construct you are referencing. Oracle has had (at least since version
6) the native extension in SQL called the CONNECT BY operator to
connect rows which reference each other in a table to form a
tree. This allows a single SQL query to do a traversal of the tree
formed by these rows.
| "Tree Processing in SQL", by David Rozenshtein shows how to handle
| queries against tree and graph structures stored in relational
| databases, the key is the choice of matching table schemas and
Sounds interesting. I've had a copy on order for this at Amazon
for several weeks. Is it already available elsewhere? Presumably these
techniques can be applied with great results in an Oracle database,
| The Oracle approach shows a tendency to think of handling XML as an
| extension of structured text processing, instead of the fundamental
| abstraction of a tree of nodes.
This is one approach that we support which caters to searching
structured text markup, like the Works of Shakespeare, syndicated
news stories marked up in XML, court documents marked up in XML,
Our approach is three-pronged.
(1) Support rich text searches of structured text markup, where
XML markup lets those searches be much more precise.
If you save all court proceedings from 1990 through 1998 for
Supreme Court Cases as XML documents in a set of generic tables
like DOM_NODE and DOM_NODE_ATTRIBUTES, I believe you'll find
the searching these using structured text searches to be a
more effective approach.
(2) Support mapping highly structured XML into/out-of a user-definable
set of tables and columns.
This means familiar SQL works over the results, traditional
tools for application-building and data-warehousing can work
with the data without modification. Externally, the data can
"travel" as XML.
(3) Support full tree-queries over your suggested abstraction
as considering an XML file just a "persisted tree of nodes"
Options (1) and (2) are in 8i, with option (3) under development
for future release. Sounds like with some of Rozenshtein's techniques,
there may be an interim solution for (3).
Hope this helps.
Steve | Consulting PM & XML Technology Evangelist | [log in to unmask]
Muench | Java Business Objects Dev Team | geocities.com/~smuench