|
TechNotes
Logic in DB
Data Access
SOX
SQL/XML
Restructuring
Trees
Open Source
BizIntel
MySQL
Drivers
ODBC
JDBC
OLE DB
.NET
Podcast
SQL:2003
MS SQL 2005
Webcast
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 Processing
Database 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.
|
|
|
