TechNotes
Logic in DB
Beyond Java
Data Access
SOX
SQL/XML
Restructuring
Trees
Open Source
BizIntel
MySQL
Drivers
ODBC
JDBC
OLE DB
.NET
Podcast
SQL:2003
MS SQL 2005
XML DBs
XQuery
Webcast
XQuery
SQL:2003
MS SQL 2005
|
|
1 2 3 4
5 6 7 8 9 Next >>
Michael M. David returns to SQLSummit.com to explore the fatal flaws in XPath navigation that are a handicap to XML databases.
Identifying the Database XML Usage Problem
Having worked with hierarchical then relational and now hierarchical structures again with XML, I have been waiting for hierarchical database processing to
progress at least to the point it was before. From this experience, I believe that XML’s use in database processing has failed to make a number of critical
corrections and improvements. This has prevented XML database processing from progressing in the way it should have by now for getting the most value out of complete
hierarchical structures by allowing non technical database users to process them fully and easily.
The cause of this problem is the continued exclusive use of procedural (user) navigation for database processing, mostly using XPath.
This has resulted in difficult, static, error prone, and time consuming hierarchical coding. This makes the majority of most possible queries impractical and those
that are practical require a database professional to specify. The result is significant limitations on XML’s database processing’s growth, usage, and acceptance.
Correcting the Database XML Usage Problem
|
 Fast, reliable data access for ODBC, JDBC, ADO.NET and XML |
Today’s database XML processing is limited basically to single-leg (linear) hierarchical processing that uses procedural navigation usually supplied by XPath. But
hierarchical structures have multiple legs and do not need to be restricted to single path queries and their processing. Powerful multi-leg (nonlinear) hierarchical
query processing was popular and successfully in use three decades ago. This processing was nonprocedural and navigationless, and also produced hierarchically correct
results by following natural hierarchical processing principles. It allowed any combination of legs to be freely referenced in any order and then processed automatically
and accurately. This is applicable again today for the database processing of XML. In this paper, I will examine the possible benefits of this powerful nonprocedural and
navigationless processing for XML that are not being utilized today.
|
Database Processing Logic Not Separate From Markup ProcessingDatabase and markup must be separately processed because they require different processing solutions. This has not happened today because XML was designed for
markup, while database use was an afterthought and is still using markup logic by default. Markup processing requires a processing strategy that includes procedural
navigation for its more variable and less formal structure processing of text processing. Database processing requires a more fixed structure processing that
supports principled and unambiguous nonlinear hierarchical data processing semantics to produce accurate results for database data. The separation of text from data
centric processing solutions benefits database processing by allowing it to specifically apply a more tightly controlled nonlinear hierarchical data processing
semantics than required for determining the wider more variable context of markup text.
1 2 3 4
5 6 7 8 9
Next >>
Database Server Watch
SQL Summit Home
Page Articles
© 2008, Ken North Computing LLC, All rights
reserved.
|
|
|
