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/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--