- From: Thorsten Trippel <ttrippel@spectrum.uni-bielefeld.de>
- Date: 15 Jan 2004 11:09:26 +0100
- To: public-qt-comments@w3.org
Reading the working draft (W3C Working Draft 12 November 2003) and testing some XQuery tools left the impression that the axis features are sort of neglected by leaving features optional, which is not acceptable. The introduction of the Full Axis Feature (section 2.6.3) open a way for implementers to claim XQuery conformity without supporting certain axis such as the sibling and ancestor axes. These might not be relevant in unordered databases such as address tables, where sorting takes place, if required, after querying; but XML data provides an essential component namely the preservation of the order. Annotation formats for speech for example rely on rather flat XML trees that maintain the linear order of speech. These annotations clearly show a data centered approach to XML, which makes it a candidate for processing with XQuery rather then XSLT. But querying such data is interesting if access not to the whole subtree but to a context is possible. The same is true for flat structured textual documents where distributional analysis of texts are required and wanted. Accessing the linear structure of XML documents is a major advantage of XML based databases for certain applications and clearly distinguishes these DBs from relational data where these access structures are not to be maintained. Especially for the processing of natural language, in data or document based XML, the full set of axis needs to be available. I would strongly recommend the change of the following: 1. Section 3.2.1 OLD sentence: XQuery supports the following axes (subject to limitations as described in 2.6.3 Full Axis Feature): <bulletlist> NEW sentence: XQuery supports the following axes: <bulletlist> 2. Section 2.6.3 needs to be deleted. Vendors will provide their personal flavors of XQuery, if the feature is in the specification or not. But at least they should not find an excuse for omitting certain axis that are justified. If necessary I can provide example queries which are needed in language databases. A workaround with user defined functions (using features such as the node number or position) or more complex contstructs is not acceptable, as it seems to violate the priciples of navigation in XML trees. Missing features like this would doom XQuery to failure in large and progressing XML using communities. Thorsten -- ----------------------------------------------------------------------------- ///////// Thorsten Trippel ttrippel@spectrum.uni-bielefeld.de // Computational Linguistics and Spoken Language // // Research Group: Text technological modelling of information // // URL: http://www.spectrum.uni-bielefeld.de/~ttrippel // Bielefeld University, Federal Republic of Germany ///////// Department of Linguistics and Literary Studies -----------------------------------------------------------------------------
Received on Thursday, 15 January 2004 05:20:16 UTC