IBM could very well be performing similar processing under the covers
My gut feel is that IBM is likely parsing the entire document under the
covers, and using call-back event handlers in order to "find" the "xpath"
that's specified by the developer. Consider the following XMLTABLE example:
*XMLTABLE*(*XMLNAMESPACES*('
http://podemo.org' *AS* "pod"),
'$po/PurchaseOrder/itemlist/item' *PASSING* P.PORDER *AS* "po"
*COLUMNS* "PO ID" *INTEGER* *PATH* '../../@POid',
"Part #" *CHAR*(6) *PATH* 'product/@pid',
"Product Name" *CHAR*(50) *PATH*
'product/pod:name',
"Quantity" *INTEGER* *PATH* 'quantity',
"Price" *DECIMAL*(9,2) *PATH*
'product/pod:price',
"Order Date" *TIMESTAMP* *PATH* '../../dateTime'
) *AS* U
If I understand correctly, the XML document contains a object hierarchy
that includes:
$po/PurchaseOrder/itemlist/item
and within that, it contains other elements that must be output to the
columns specified:
"PO ID", "Part #", "Product Name", "Quanty", "Price", and "Order Date"
I can't think of a better way of handling that type of syntax, other than
using a call-back procedure that would monitor for the occurrence of
elements such as:
<PurchaseOrder>
<itemlist>
<item>
<quantity>
<dateTime>
and so forth.
do think though that IBM's developers will typically have the requirement,
expertise, budget, and developer time to do a better job at optimization
than most of us do.
Okay, but XML-SAX and XMLTABLE are both IBM implementations, and that's
what we're comparing. We're not comparing what developers may be doing in
call-back procedures (in the case of XML-SAX), or while processing a cursor
(in the case of XMLTABLE). One could even argue that the generation of an
intermediate cursor in the case of XMLTABLE would add unnecessary overhead
(mapping, handling various data types, etc).
midrange.com
