Home Up Logic in DB XPath Sun MySQL Rock MySQL Security Fix OLTP


Fast, reliable data access for ODBC, JDBC, ADO.NET and XML
WSSC 2008: An event dedicated to SOA and Web Services Security
Got SOX compliance?
Movielink Logo 88x31
Business Intelligence with R&R ReportWorks
IBM eserver xSeries 306m 8849 - P4 3.4 GHz
iTunes Logo 88x31-1

Navigation and XPath Holding Back Database XML Industry

Logic in DB

Data Access



Open Source




MS SQL 2005


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.

Michael M. David
Advanced Data Access Technologies, Inc.

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 WatchSQL Summit Home Page††† Articles†

Visit GridSummit.com (Grid Computing Knowledge Portal)

© 2008, Ken North Computing LLC, All rights reserved.

Movielink Generic 120X90 Animated