What's Still Wrong With SQL Native XML Integration Solutions
The SQL native XML integration market has not yet taken off. On the face of it, it is easy to see why. Every vendor has a different proprietary solution, all of these solutions are incompatible with each other, and none of these solutions has satisfactorily solved the relational and XML data integration problem. This data integration problem is at the hart of this industry acceptance problem. Lets examine the separate data integration areas that comprise this basic data integration industry problem and then look at a possible solution that is already in the ANSI SQL processing box.
XML Database Processing Industry Basic Problems
An SQL processor with native XML integration is an XML database processor. One of an XML database processor's primary requirements is to output fully structured XML. XML is hierarchical, so the XML input and output needs to be hierarchically valid to be useful. This also means it needs to be hierarchically: processed, preserved, and structured correctly. XML database processor designers have seemed to ignore this requirement. Their products do not impose or require hierarchical processing. This means that their XML product's data may not be hierarchically correct, which also means their result data is incorrect. So why do current XML database processor products allow non hierarchical operations which will invalidate the XML hierarchical result?
This non hierarchical problem stems from the fact that XML was designed for markup and not for database data. These are very different uses. XML's use for database data was realized after the XML specification had already been finalized and put into practice. For this reason, XML for database use was not thought out very well and evolved in a haphazard fashion. This occurred because the XML spec does not say one word on how the XML database data is to be hierarchically processed because it was not intended for that purpose. This is another significant problem. Even when XML data is processed hierarchically, there is no XML specification for this. So every vendor has come up with their own XML processing procedures that may not be hierarchically valid.
A third problem is the collective relational mindset in the XML industry that continues using a relational processing model for XML processing. As evidence of this relational mindset, even XQuery designed from scratch to handle XML processing naturally supports the relational inner join operation by default. The inner join is not a hierarchical operation and will invalidate hierarchical data it is applied to. This does not make good sense for an XML product that is designed for XML processing and output.
SQL Native XML Integration Externally Perceived Problems
The above mentioned XML database processing industry basic problems: 1) XML database processing not fully hierarchical, 2) No hierarchical processing specification that must be followed, 3) Overly influenced by the relational mindset of the XML product designers, all come together to produce many SQL native XML integration externally perceived processing problems. These are:
1) Multiple incompatible solutions on the market 2) Solutions that are proprietary and/or non standard 3) Having to use SQL native XML centric and procedural syntax 4) Solutions that do not solve XML and relational data integration 5) Non principled hierarchical processing, producing invalid hierarchical results 6) Hierarchical processing basically limited to single leg (linear) processing
An ANSI SQL Native XML Integration Solution
Interestingly, the wrong solution to use, relational SQL for XML processing, turns into the perfect solution when it is realized that ANSI SQL can perform full hierarchical processing automatically when properly instructed in SQL. The ANSI SQL-92 standard introduced the Left Outer Join operation that precisely models hierarchical structures. Using only this Left Outer Join operation to model full hierarchical structures does produce the correct hierarchical results based on natural hierarchical principles followed precisely by the Left Outer Join hierarchical semantics. Since the Left Outer Join can model multi-leg structures, advanced nonlinear hierarchical processing is also inherently supported. This powerful hierarchical processing can be used to automatically solve all the SQL native XML integration problems identified above.
This is not an immediate SQL native XML integration solution. While every ANSI SQL processor can perform full hierarchical processing when instructed to, the internal relational engine does not know that it is processing the data hierarchically. This means it cannot automatically take the final step to fully utilize this powerful hierarchical processing for XML integration. But the capability is available. This is where SQLfX® comes into play. It fully leverages this powerful hierarchical processing capability so that the underlying hierarchical processor fully processes native XML from input through processing to XML structured output in ANSI SQL. And this occurs transparently using no XML centric syntax or navigation.
Producing correct XML hierarchical results automatically from generic ANSI SQL query processing, leaves very little room for different proprietary and incompatible solutions. This is because there can be only one correct answer for each ANSI SQL query. SQLfX® delivers this level of performance.
For more information on the SQL native XML integration solution, select here.