[
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.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
