Querying XML: Use Cases - Further Discussion of the W3C XML Query-Use Cases in XSLT
(Page 5 of 5 )
XSLT 1.0
Unlike most other examples in this book, this one is a smorgasbord of prepared meals. Querying XML can mean so many things that are difficult to come up with generic recipes. The W3C did a decent job classifying the kinds of queries that come up in various domains. The demonstration of these query solutions in XSLT should provide a sound base for approaching many types of query problems.
Due to space considerations, this chapter did not include the XQuery solutions to the previous problems. Nevertheless, contrasting the two approaches is instructive, so I encourage the reader to examine the W3C Query Use Case document.
Providing individual commentary on each query implemented earlier would be impractical. However, most readers with basic XSLT skills should have little trouble deciphering the solution. Many solutions shown have alternate solutions in XSLT. Some of the alternatives may actually be better than the ones in this chapter. My solutions were heavily influenced by the XQuery solution presented in the original W3C document. However, I also tried to vary the XSLT constructs used, sometimes favoring an iterative style (xsl:for-each) and other times using the declarative style provided by patterns and xsl:apply-templates.
XSLT 2.0
This chapter is quite large so I did not repeat all the solutions using 2.0. However, there are some select problems that illustrate the kinds of improvements one can achieve using the facilities of XPath 2.0 and XSLT 2.0:
Take advantage offor-each-groupor distinct-values()when you need to eliminate duplicates.
Question 4. For each author in bib.xml, list the author's name and the titles of all books by that author, grouped inside a "result" element:
Question 8. In the document books.xml, find all section or chapter titles that contain the word "XML", regardless of the nesting level: <results> <xsl:sequence select="(//chapter | //section)/title)[contains(.,'XML')]"/> </results>
Take advantage of functions and sequences to simplify queries.
<!--No need for node set conversions. Use descendants function directly --> <xsl:for-each select="ckbk:descendants(.,/)[current() != .]"> <xsl:sort select="count(./* | $everyone[@name = current()/@spouse]/*)" order="descending" data-type="number"/> <xsl:sort select="@name"/> <xsl:variable name="mstatus" select="if (@spouse) then 'Yes' else 'No'"/> <person married="{$mstatus}" nkids="{count(./* | key('person-key', @spouse)/*)}"> <xsl:value-of select="@name"/> </person> </xsl:for-each> </xsl:template> <!-- Note how this function is simpler than the template in the XSLT 1.0 solution. We pass in the doc because it is unknown inside of functions.--> <xsl:function name="ckbk:descendants"> <xsl:param name="nodes" as="item()*"/> <xsl:param name="doc"/> <xsl:sequence select="$nodes, for $person in $nodes return ckbk:descendants( ($person/person, key('person-key', $person/@spouse,$doc)/person), $doc)"/> </xsl:function>
</xsl:stylesheet>
See Also
Evan Lenz has also explored the topic of using XSLT in place of XQuery (http:// xmlportfolio.com/xquery.html).
* A mathematician will tell you that the intersection of a set with itself will always yield the same set. This is true for proper sets (with no duplicates). However, here you are using an application-specific notion of equality, and the node sets typically will not be proper sets under that equality test. However, the value-set operations always produce proper sets, so this technique is a way of removing duplicates.
* It outputs both gender and sex attributes, but you knew that already!
* These use cases were dropped from the latest version of the W3C document.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.