[xsl] What is exciting in XSLT 2.0 (Was: Re: [xsl] parameters in XSLT 2.0)

Subject: [xsl] What is exciting in XSLT 2.0 (Was: Re: [xsl] parameters in XSLT 2.0)
From: "Olivier Collioud" <olivier.collioud@xxxxxxxx>
Date: Wed, 08 Jun 2005 13:52:27 +0200

I must confess that I don't even know the meaning of much of these
and I'm sure that many peoples (not coming functional programming
world) are in the same situation.

It would be very valuable for someone like me to see some examples
illustrating each of these topics
(also showing how similar things are done in 1.0).



>>> dnovatchev@xxxxxxxxx 8/06/05 1:37:29 PM >>>
With the introduction of xsl:function in XSLT 2.0 there are a number
of extremely interesting and important topics that are now becomming
more relevant but (I wonder why), are rarely discussed on this list.

   Function overloading -- limitations and how to overcome them.

   Parameter typing -- specific vs more general types, polymorhism,
how to determine dynamically the type of an actual argument, passing
functions as parameters.

   Function return type -- same as above plus returning a function as
the result, plus non-pure functions.

  Sequences  -- serialization/deserialization.

  Higher-order functions, partial application, controlling the
sequence of evaluation.


   Function libraries (it's a pity we can't have them in compiled

  Modelling the "continuation-passing" style.

Isn't this breathtaking!

Dimitre Novatchev

On 6/8/05, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > First, am I right that if I use an "as" attribute of element() or
> > node() I am passing a reference to the original element or node,
> > thus that this is an efficient operation?
> In the examples below you are passing a reference. If you used
> rather that xsl:sequence you would be creating a copy.
> The effect of using "as" on performance may be positive or negative.
It may
> cause the system to do run-time checks that would otherwise not be
> performed. On the other hand, it gives the system compile-time
> that may be useful to perform optimizations. I would use it as widely
> possible because it speeds the development cycle and catches bugs
> efficiently, and not worry too much about any effect on performance.
> >
> > Related, am I correct that these below are equivalent from a
> > processing
> > standpoint?
> >
> > <xsl:variable name="foo" select="bar" as="element()"/>
> >
> > <xsl:variable name="foo" as="element()">
> >    <xsl:sequence select="bar"/>
> > </xsl:variable>
> Yes.
> >
> > Finally, in general, under what conditions should one use tunnel
> > parameters?  I do a lot of parameter passing in my
> > stylesheets, though
> > the content of those parameters is typically fixed.
> >
> Use them if A calls E via B, C, and D, and you want to get
information from
> A to E without cluttering the code of templates B, C, and D. The most
> use-case for this is if you are reusing existing templates B, C, and
D and
> want to reuse them unchanged.
> Michael Kay
> http://www.saxonica.com/ 

World Intellectual Property Organization Disclaimer:

This electronic message may contain privileged, confidential and
copyright protected information. If you have received this e-mail
by mistake, please immediately notify the sender and delete this
e-mail and all its attachments. Please ensure all e-mail attachments
are scanned for viruses prior to opening or using.

Current Thread