OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ 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 

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS