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

Re: XPath/XSLT 2.0 concerns

• To: Jeni Tennison <jeni@j...>
• Subject: Re: XPath/XSLT 2.0 concerns
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Sun, 06 Oct 2002 22:47:16 -0600
• Cc: "Michael Kay" <michael.h.kay@n...>, "'Mike Champion'" <mc@x...>, xml-dev@l...
• In-reply-to: Message from Jeni Tennison <jeni@j...> of "Wed, 02 Oct 2002 20:31:52 BST." <19534340120.20021002203152@j...>
• Sender: uche.ogbuji@f...

> 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

• Follow-Ups:
  • Re: XPath/XSLT 2.0 concerns
    • From: Jeni Tennison <jeni@j...>

• References:
  • Re: XPath/XSLT 2.0 concerns
    • From: Jeni Tennison <jeni@j...>

• Prev by Date: Re: limits of the generic
• Next by Date: Re: XPath/XSLT 2.0 concerns (off topic)
• Previous by thread: Re: XPath/XSLT 2.0 concerns (off topic)
• Next by thread: Re: XPath/XSLT 2.0 concerns
• Index(es):
  • Date
  • Thread