Subject: Re: [xsl] What's your visual metaphor for XSL Transformations? From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> Date: Fri, 23 Mar 2007 06:07:51 -0700 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] What's your visual metaph, bryan rasmussen | Thread | Re: [xsl] What's your visual metaph, bryan rasmussen |
Re: [xsl] What's your visual metaph, bryan rasmussen | Date | [xsl] [newbie] no output for othell, Une Bévue |
Month |