[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XQuery -- Reinventing the Wheel?
> XPath 1.0 does not, XPath 2.0 or XSLT 2.0 may (or whatever the wording in > their requirement document is). The document() function is really not a > replacement since it does not scale well to 10'000s of XML > fragments/documents. document() is no more than a URI resolver. There is nothing that says it must bring 10,000 documents into memory. This just the way it happens to be implemented in a lot of first-generation processors. I have stated that I think some efficient query primitives might need to be added to XSLT, probably in the form of extension elements, but I hardly think that qualms about document() are excuse to reinvent the entire framework. I should point out that XSLT 2.0's proposed datatyping fills another gap for a large-scale XML query language. > Evan, you actually left out an important result of your simplistic formula, > by elminiating the template rules and stratifying some of the semantics, > XQuery aims to become better optimizable for people that care about > performance and scalability. It also will become strongly typed if complex > and simple type is available, which XSLT 2.0 will not be. Strongly typed can be dangerous when we're dealing with semi-structured data. Is XQuery's goal dealing with endless regiments of entirely predictable data, large volumes of POP-style data, or both? I have my doubts that a single mechanism is a universal solvent for both. So as XSLT matures, specialized techniques can and will branch out for optimizing particular usage patterns. > Don't get me wrong: For data-driven transformations XSLT's rule driven > approach is great. The only problem is that have not yet seen a high > performance/highly scalable engine for rule-based engines (and projects such > as the ICSI project on a highly-parallel rule inference engine don't count, > they normally test the boundary of hardware (cost)) that can compare to a > algebra-based query engine with optimizer. Are we all forgetting how long it took the first relational databases to achieve decent performance? I still remember the tremendous fanfare generated by (pre-Microsoft) FoxPro's "Rushmore" technology, the sort of thing which is considered quotidian these days. I still need to hear these pressing arguments that XSLT is *fundamentally* incapable for large-scale query. The state of first-generation implemenations is no argument. There will also be a first generation of XQuery engines. > So for acceptance of a query language in the data community, a query > language a la XQuery will find larger acceptance and more efficient > implementations. Evidence? Don't get me wrong either. I'm not categorically saying XQuery is otiose. I'm just looking for the compelling impetus not to build it within the XSLT framework. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
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
|