[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: need for defining standard APIs for xml storage

  • From: "Didier PH Martin" <martind@n...>
  • To: <n.vinokurov@m...>, "gopi" <gopi@a...>
  • Date: Tue, 28 Mar 2000 11:18:17 -0500

selectnodes x path
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@n...
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@n...
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@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.