Templates in XQueryMartin Probst mail at martin-probst.com
Sun Sep 5 12:28:14 PDT 2010
> Can someone try to present few use cases, that how XQuery functions > calling xsl:apply:templates really helps? I'd think of use cases such as transforming larger parts of semi-structured XML. I.e., XML that has a free form structure, as opposed to data centric XML that has a rigid, predictable structure. Writing lots of recursive XQuery functions with typeswitches is just annoying for that, and if you have more complex rules that don't fit into a typeswitch, it gets worse with if/then/else chains. Basically anything that fits the description of "do this for each of the nodes in the tree, recursively, and pick rules by tree structure". The other use case is people that do not want to (or cannot, because of technical limitations) implement their own glue layer that pipes XQuery results into XSLT efficiently. I'm not entirely sure if that's a valid use case - most environments have a host language for that, and XProc may or may not solve that problem more elegantly. > I think, providing this > functionality into XQuery (and also designing the receivers on XSLT > side) is to accept significant complexity within the implementations. > On XQuery side, the XQuery engine must create the context and build > the input tree to pass on to an XSLT engine. On XSLT side, the XSLT > engine needs to accept this as a new kind of InputSource (it may > though wrap this new input from XQuery side, into it's existing input > sources) and also create a XSLT specific context, and return the > results on an XQuery side. Depends on how you do that, and whether you already have some XSLT processor available. If you're living on the Java platform, this might be as simple as instantiating the template and passing a new DOMSource(xquery result node) to it. The devil is of course in the details, with questions about schema type information and the various options an XSLT processor might take, which might complicate the interface. > This is certainly doable by implementations, given the maturity of > XQuery and XSLT implementations we have today. But this carries > significant burden to implementers. I think we must present sufficient > number of use cases for the benefits in this area, before expecting > implementations to provide these features (and also the specs defining > them). This "XQuery is lacking templates/integration with XSLT" seems to come up quite a bit. That of course doesn't mean it's really needed, and it also doesn't mean this approach is really the solution to the (perceived) problem in the first place. So yes, we'd need more user requirements. Martin
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