Okay 2 things here;

1.
I would like the examples of these things. Not because I don't believe
they exist but because I would like to see if there are some I hadn't
thought of before (is this 2.0 we're talking about, probably give lots
more examples that way)

There are plenty of XSLT 1.0 examples of useful transformations that
do not need/use a source xml document.

Take for example Jeni's famous stylesheets that you have to
double-click on their names in Windows Explorer in order to get them
going.

Jeni is one of the most brilliant people I have met and I do miss her
presence in this list.

2. There may be no reason why a transformation should not be unlimited
in time but then I suppose the transformation engine needs to output
in some way and drop the output from its memory. I could see this
easier in xsieve than in xslt actually.

Is there any implementation of this kind of endless transformation engine?

To be more precise, it is a transformation that can be *unlimited, or
indefinite* in time, not the transformation engine. Any compliant
transformation engine must just do what the transformation specifies
-- in case a transformation runs for a long period of time there is no
provision in any XSLT spec that this is an unusual situation. In fact,
the notion of *length of execution* is entirely missing from the
specs, which I think is the correct way to specify a functional
language.

To return back to examples, in April 2002 I did publish an example of
an XSLT 1.0 transformation that can potentially run for as long as
needed. It also is not something artificially contrived and actually
produces useful results for its end user.

It is very easy to explain what this transformation does, how it
performs its work and why it can perform for an unlimited time, as
long as its services are needed.

however the essentials are just in the following few lines of code,
quoted from this source:

 <!--
  This template gets back every new request from the
  calculator.
  A request has the form:

     <calc>
       <op>+</op>
       <arg>3</arg>
       <arg>5</arg>
     </calc>

  When the value of <op> is "q", then this template does
  nothing and simply returns, which ends the dialog.
  Otherwise, every known operation is evaluated using
  the math functions of FXSL.

  The template calls itself recursively with the result of
  displaying the result to the user (done via an method of
  an external object). This result is either a new request
  for calculation, or the quit-op ("q").
-->

 <xsl:template name="keepDialog">
   <xsl:param name="pInput" select="/.."/>

   <xsl:if test="not($vOp = 'q')">
     <xsl:variable name="vResult">
       <xsl:call-template name="evalOp">
         <xsl:with-param name="pOp" select="$vOp"/>
         <xsl:with-param name="pArg1"
                         select="$pInput/calc/arg[1]"/>
         <xsl:with-param name="pArg2"
                         select="$pInput/calc/arg[2]"/>
       </xsl:call-template>
     </xsl:variable>

     <xsl:call-template name="keepDialog">
       <xsl:with-param name="pInput"
         select="myObj2:dispResult(string($vResult))"/>
     </xsl:call-template>
   </xsl:if>
 </xsl:template>

This was 5 years ago. Since then XSLT 2.0 has made it even more
natural and easier to express such transformations. Abel mentioned the
unparsed-text() function and I have been referring to the
possibilities provided by the <xsl:result-document .../> instruction.

So, there's nothing new about the real and practical possibility to
use XSLT for any kind of processing that comes to mind.

The usefulness of saying this once more is that people, who somehow
missed this, are now better informed.

--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play

Cheers,
Bryan Rasmussen

On 3/22/07, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
> > 3) The recursion is finite or needs to be finite. In the case of XML
> > and XSLT the finiteness is defined by the depth of the XML nodes that
> > are being traversed recursively. In the case of functions it is some
> > condition that breaks the recursion.
>
>
> Just to repeat:
>
>   There are no technical or practical reasons why a transformation
> should not be unlimited in time.
>
>   People are seriouly considering XSLT transformations that implement
> fundamenal (and non-stop) server-side logic.
>
> If one can have such applications implemented in the impertive style,
> nothing can prevent them from being implemented in the funtional
> style. There have been HTTP servers written in Haskell and that's OK.
>
>
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> You've achieved success in your field when you don't know whether what
> you're doing is work or play
>
>
> On 3/22/07, Rashmi Rubdi <rashmi.sub@xxxxxxxxx> wrote:
> > Thanks to everyone for your replies on visualizing recursion. I will
> > take some time to read everyone's replies.
> >
> > I feel that knowing the characteristics of a recursive function / XSL
> > template makes it
> > easier to write them.
> >
> > At the simplest level those characteristics are
> >
> > 1) A recursive template/function calls itself
> >
> > 2) The call to itself is at the end of the function
> >
> > 3) The recursion is finite or needs to be finite. In the case of XML
> > and XSLT the finiteness is defined by the depth of the XML nodes that
> > are being traversed recursively. In the case of functions it is some
> > condition that breaks the recursion.
> >
> > At the next level of complexity, would be one function or template
> > calling another recursively and many other variations of the above
> > simple case.
> >
> > -Rashmi