[
Lists Home |
Date Index |
Thread Index
]
> 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
|
