Re: XPath/XSLT 2.0 concerns
Hi Mike, > Well, the more I think about it, the more I think that people are > actually using match patterns as a sort of "structural type > detection" mechanism. People write template rules that say "when I > get one of these, do this", and they are defining "one of these" by > means of a pattern that is in effect a type. Now very often there's > a one-to-one mapping between these types and element names, so the > patterns are very simple. But I think that once people are dealing > with really large vocabularies, constructing the patterns in terms > of element names gets more and more difficult, and being able to > match against types at different levels of a type hierarchy gets > more and more valuable. I agree with this, very much. Actually I think we can break this pattern down into two classes: 1. grouping elements based on their *content* -- in other words, the *type* hierarchy 2. grouping elements based on their *context* -- in other words, the *substitution group* hierarchy An example of 1 is dealing with all addresses in the same way, whether the element that holds the address is a <buyerAddr> or <supplierAddr> element. An example of 2 is dealing with all block-level elements in the same way, whether they're paragraphs, tables or lists (all of which have very different content). There might be different proportions of 1 and 2 in different kinds of structures -- more of 1 in data-oriented structures, more of 2 in document-oriented structures; I'm not sure. Certainly, looking at the stylesheets I've written recently, I see use cases for both kinds. The current focus in XPath/XQuery is very much on 1 rather than 2. 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