> I'm thinking mostly about generalized processors that want to 
> be able to
> examine the type heirarchy of an element to see if it is a type they
> recognize, i.e., in this example a generic table renderer that expects
> the base types of table elements to be types it recognizes. I need to
> see what the XSLT processing implications are....

There's a lot of support for this kind of thing in XPath 2.0 and XSLT 2.0.

<xsl:template match="schema-element(ABC)">

matches any element whose name is ABC or a name in the substitution group of
ABC (which must be the name of a global element declaration)

<xsl:template match="element(*, XYZtype)">

matches any element whose schema-type is XYZtype or a type derived from
XYZtype, which must be a named simple or complex type definition in the
schema.

So in principle the mechanisms are there to define processing at whatever
level of the type hierarchy you want, and this applies whether you are
specializing by using substitution groups or by deriving types. 

But I agree with you that it's not easy to work out which of these
facilities to use in a given situation.

Michael Kay
http://www.saxonica.com/



From ekimber@i... Thu Mar 24 15:55:16 2005
Recei