> Is it fair to say that, in XSLT 2.0, type declaration
> extensions are likely to have the same status that
> extension functions had in XSLT 1.0?  In particular,
> a separate implementation for each XSLT vendor?

Yes.
> 
> Would it be reasonable for XSLT 2.0 to specify an XSLT
> function API for type management (including type
> declaration)?  If the XSLT vendor has to implement
> types anyway, would a standard interface increase 
> the implementation effort substantially?

The XSL WG (and W3C generally) has been steering clear of APIs. The attempt
to standardize extension function bindings in XSLT 1.1 was widely disliked,
so I can't see it being attempted again. In any case, there's a need for a
lot more vendor experimentation and experience before anyone really knows
what is likely to work.
> 
> In particular, if you're interested only in matching
> based on type and not in validating, would you 
> require only the subset of the abstract model that 
> names each type, identifies its base type, and 
> provides type annotation for elements?
> 

Yes, pretty well. To describe it in Saxon terms, all you need to do is:

(a) attach type annotations to nodes in the source document. You can do this
by using interfaces to the document builder. The type annotation is an
integer, corresponding to a QName - you can allocate integers to QNames by
calls on the NamePool service.

(b) create a schema (a Java object that indexes type definitions by name)
and register it with the Saxon Configuration. The Schema returns a
SchemaType object when given the integer used as a type annotation.

(c) implement the type definition objects. This object provides a method
type.matchesItem(item) which returns true if the item (e.g. a node) is an
instance of the required type. This gives you the "instance of" operator,
which you can then use in your match patterns.

In practice it's going to be a bit more complicated than that, but that's
the view from the stratosphere.

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