[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath/XSLT 2.0 concerns

apache xslt 2.0
> 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 

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.
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.