Re: xslt 2.0 suggestion -- explicit extensions, and support for next-match

To begin, I should note that by explicit extensions or specialization, I
mean a mechanism for declaring that one template is a specialization of
another template, in the same spirit as declaring that one object class
extends/specializes another in OO programming, or one type extends another
in XML Schema.  This has nothing to do with extension functions, in case
there was any confusion.

Also, in case it was not clear, the next-match capability that I referred to
has already been suggested for inclusion in xslt 2.0 (last I checked).  The
point of my message was to provide support for including this feature, by
noting an additional use case a la the Visitor pattern (cf the templated
named DoB as a specialization of DoA in my original post), and to say that
this feature would be even more useful in concert with the suggestion to
allow the explicit declaration of specialization relationships.

In your reply, you state:

>I your explanation you say:
>
>"Of course, you could do without explicit extensions and instead make the
>user assign priorities, but this would be less user friendly."
>
>This is not the case because only the highest priority will match. Within a
>template there is no way to direct apply-templates to another template
>which would also match but which has a lower priority. However, this is
>needed to implement the equivalent of "next-match", which is an enveloping
>mechanism.

I think this is correct for xslt 1.0; I was talking about what I'd like to
see in xslt 2.0, in addition to the proposed next-match capability.

You then write:

>Another thing is that the "extensions" are aware of being an extension.
This is
>not necessary.

In my view, it's a good idea to have templates that are intended to be
specializations of more general or default templates declared as such; this
would not be evident just by assigning a higher priority to the
specialization.  Also, if matching conditions are to be implicitly and-ed --
ie, if a specialization is only allowed to match in more restrictive
circumstances than the template it extends, as we have found to be useful --
then an explicit declaration does become necessary.  Plus, explicitly
declared specializations would allow a selection mechanism to be used with
call-template as well as with apply-templates.

Later you make a suggestion which seems to be an alternative to next-match:

>I propose a small extension for this which has very little impact on the
>current process model, which says that only one template may match for some
>node. The solution would consist of adding the optional "max-priority"
attribute
>to the "apply-templates" element. Its meaning is that templates with a
priority
>above max-priority are not considered for the current node.

To me, the max-priority idea doesn't seem that much different from
next-match -- it just forces one to play with priorities, which is less
declarative.  On the other hand, perhaps it would be considerably easier to
implement.  Here's how I would list the options, in both increasing
desirability and distance from xslt 1.0:

* apply-templates with max-priority attribute
* next-match
* explicit specializations
* implicit and-ing of match conditions across specializations
* similar selection mechanism for call-template

I'm not sure what the current timetable is for xslt 2.0, but I'd love to at
least see next-match or the max-priority qualifier included.

Regards,

Michael White
CoGenTex, Inc.

Received on Thursday, 15 November 2001 03:53:25 UTC