Higher-Order Functions in XSLT (Was: RE: xslt 2.0 suggestion -- explicit extensions, and support for next-match)

Let's call things with their proper names -- you're talking here about a particular
case of functional composition.

By now, it should have become quite clear, that support for higher-order functions
in XPath 2.0 and XSLT 2.0 is the logical and necessary foundation for this and other
similar proposed extensions.

Although higher order functions can be implemented in XSLT 1.0 through the mechanism
of generic templates (see several of my recent posts in the xslt-list), a standard
support for this feature would significantly facilitate the development of
functional-style XSLT applications, by making the definition and application of
higher-order functions in XSLT more straightforward, natural, compact and reliable.

This would lead to the creation of wide-coverage function libraries, to a
significant leap in problem solving capability, and ultimately to much higher XSLT
developer's productivity.

Failure to provide standard support for higher-order functions in XPath 2.0 and XSLT
2.0 will lead to a multitude of incompatible partial implementations of special
cases that are difficult or impossible to re-use or combine together, to cluttered
thinking, to inability to define and treat large general classes of problems and the
necessity to spend much more time and effort in solving just some special cases of
such general problems.

Dimitre Novatchev.

> -----Original Message-----
> From: "Kay, Michael" <Michael.Kay@softwareag.com>
> To: "'Michael White'" <mike@cogentex.com>, xsl-editors@w3.org, w3c-xsl-wg@w3.org
> Date: Fri, 16 Nov 2001 13:32:14 +0100
> Subject: 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.
> > 



__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

Received on Saturday, 17 November 2001 07:14:10 UTC