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. While I can understand, and perhaps with your reasoning here, I must say that I write a *lot* of XSLT and have never once come across the need for either (1) or (2). I have also worked with a lot of other people's XSLT, and haven't seen very many usage patterns that would be simplified by template matches based on types. So I have to agree with Tim Bray that this need seems to be overblown. Nevertheless, a generic annotation system would solve both these requirements, no? Statically typed XPatterns are not the obvious solution to even (1) and (2). -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/ Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py. html Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w ebservices/library/ws-pyth10.html
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