xml-dev - RE: need for defining standard APIs for xml storage

["Didier PH Martin" <martind@netfolder.com>]

Hi Nikita,

Nikita said:
Ok, Now it is clear for me.
First thing that directs me is the minimal number of specifications.
May be we can restrict ourselfs by changing slightly DOM spec, say by adding
just one more method like:

	NodeList getNodesByPath( path );

(I want to see an analogy with File System vNodes where the function
vn_lookup() presents. Saying truth, I would like to see an XML-FS).

So the DOM implementation with this method can cash and index the paths that
it
accepts from the method arguments. No additional XSE modules needed (IMHO),
only one high-level function in DOM ;-). All the DOM is completely supplied
by
database vendor. I think it is a sufficient decision..?

Didier replies:
I totally agree. I made several experiments in Didier's labs with the
Microsoft' DOM extension that allows to return a node-set from an XPath
expression and found it tremendously useful. In the Microsoft universe it is
simply stated as nodeset= selectNodes(XPath expression). So whatever we have
it named as long as we have this kind of function.

In fact, the impact of such function is that we can decouple an information
set implementation from an XSLT interpreter. This also has as a secondary
impact that such information set can be made permanent (hence to have an
XSLT engine to run on a permanent information set) or that the information
set engine can interpret the XPath expression in such ways that a relational
database is queried and a node set returned. So to speak to have an
information set engine as a data source source wrapper and have XPath as a
query language. The data sources can be organized into a hierarchical
taxonomy. Hence, we could finally have the Grove concept to appear in XML
land.

Maybe so that we do not restrict ourselves to a single query language I
would suggest a name like:

selectNodeWithXPath so that we can add later on something like
selectNodeWith.... (... are to be replaced with other query expressions). Or
that we state that XPath will evolve to allows us to build more complex
queries. In this last case, no needs to add the XPath precision in the
function name. Does anyone investigated an extended XPath that allows more
sophisticated queries (at least as sophisticated as SQL).

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com

cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************