|
From: Guillaume R. <ro...@cc...> - 2002-10-29 23:40:27
|
Le Mardi 29 Octobre 2002 21:12, Hobern, Donald a =E9crit : > In the meetings in Brazil Guillaume suggested that we might standardise a= ll > our data storage as XML documents and then rely on XPath pattern matching. > (If this is a misrepresentation, please forgive me.) I argued that this > might be undesirable in that it may be difficult to turn arbitrary XPath > patterns into SQL statements for arbitrary database schemas and that this > might therefore place an unnecessary technology constraint on provider > implementers. Actually, i only suggested to standardise external view of our data storage= as=20 virtual XML documents, whetever technology is used behind the scene, so as = to=20 express our queries following a consensus model, the federative schema. The question of how to translate an incoming xpath query into the most=20 efficient native-format query is just a technical issue. Anyone able to=20 produce the global DOM tree (or global SAX events set) from its dataset is= =20 able to run the xpath statement on it anyway. > However from what I have read of XQuery, it seems to be aiming to become a > plausible standard for addressing our problem and I need to understand it > further. We certainly do not want to end up with a totally bespoke XML > language for defining queries if a widely accepted standard for doing the > same thing is likely to appear in the near future. A rapid web research shows that XQuery is official W3C effort toward XML qu= ery=20 language, and it is going to be largely incorporated in XPath 2.=20 But there are also other query languages developped elsewhere: =2D XQL (http://www.ibiblio.org/xql) =2D QUILT (http://www.almaden.ibm.com/cs/people/chamberlin/quilt.html) =2D LOREL (http://www-db.stanford.edu/lore) =2D XML-QL (http://www.w3.org/TR/1998/NOTE-xml-ql-19980819) I guess however that XQuery is the safer bet. =2D-=20 Guillaume Rousse <ro...@cc...> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html |