[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
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|