RE: xslt 2.0 suggestion -- explicit extensions, and support fo r next-match

I'm a bit confused as to which bits of text here were written by whom. But
never mind. There's a recognized requirement in this area, and we should try
to do something to meet it. I don't think it's going to be particularly easy
to come up with a solution that's really clean, given that we're not
starting with a blank sheet of paper, but there are ideas here that might
point to a way forward. It might be something that we have to defer until
after the first WD of XSLT 2.0.

Mike Kay

> -----Original Message-----
> From: Michael White [mailto:mike@cogentex.com]
> Sent: 14 November 2001 17:58
> To: xsl-editors@w3.org; w3c-xsl-wg@w3.org
> Subject: 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 Friday, 16 November 2001 07:32:28 UTC