[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath 2.0 - how much of XQuery should it include?
Elliotte Rusty Harold wrote: > Maybe they need to be less so. XSLT 1.0/XPath 1.0 was designed for > document transformations and browser display. It was not designed as > a general purpose XML query language. Now that new and very > different use cases and requirements are getting piled on top of it, > it's beginning to look not nearly as pretty. > > I think maybe we need less general tools, not more. I think perhaps > it's time to consider whether merging XQuery and XPath and XSLT > actually makes sense. This may have been a mistake. The needs of the > communities involved may be just too different for them to > comfortably use the same tools. One of the things that's been illuminating for me over the past few days discussion has been how different the assumptions are between XQuery and XSLT users about how their respective languages are going to be used -- what kind of assumptions can be made about the source of the information the two languages are going to operate over, and the workflow that surrounds the query or transformation? In XQuery, I think you generally have a large store of information in a known format. Since such an information store will have check-in/check-out facilities, you can pretty much guarantee that the information within the information store will be valid. Each information store (which is treated as an XML document but is probably actually a database) is likely to have several queries associated with it, in order to extract different information. Generally this is a filtering of the information available in the information store; you're unlikely to add information that isn't from the information store itself. Each query is individually likely to be quite short, and there are few assumptions about the way in which the result of the query is used later on -- what the target of the query will be. Once a query is written, it will be associated with the information store, and compiled. Like the check-in process for information, checking in the query will involve checking it and compiling it so that everything runs as fast as possible when the query is actually made. The query will be executed many times on the information store, keeping up to date with the changing contents of the information store. The query itself is not parameterised -- if you want the query to extract slightly different information, then you do that by writing another query; it's expected that the users of the information store will be able to write a query themselves, or will have close enough association with the information store administration staff that they can get them to write it for them. The querying process occurs at the beginning of a pipeline, when extracting information from the information store. In XSLT, I think you generally have a set of documents that have something in common -- that something could just be that they're written in XML, or it could be that they contain elements in a particular markup language (such as XInclude or RDF), or it could be that you know the ostensible markup language for the entire document. Usually, you can't make many guarantees about the validity of the document. Each set of documents is likely to have several transformations associated with it, mostly creating different layouts or formats the information. Generally this is a translation into a different markup language, a reorganisation, and an addition of information such as standard text, headings and so on. Each stylesheet tends to be quite long, and is usually constructed with a particular target application in mind, such as an SVG viewer or an HTML browser or an XSL-FO renderer. The stylesheet will be made available somewhere, and used in a variety of ways, with usually few guarantees about what those situations might be. Each application that uses the stylesheet has to compile it and run it, usually both at the same time, though an application might compile it and use it several times over different documents. Stylesheets are often parameterised, so that different users can configure the stylesheet to create the output that's required; it's not expected that the users of the stylesheets will know enough XSLT to be able to write their own, so they'll usually be supplied with a configuration mechanism, often an XML document, to make the task simpler. Transformations generally occur in the middle or end of a pipeline, between information extraction and application-specific presentation. You might have several transformations piped together to perform different kinds of transformation. Do people think those are fair characterisations? I admit I'm not that familiar with the XQuery side of the coin, so I'd be interested if I was characterising it inaccurately or if there were other distinctions that I've left out. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
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
|