Re: [xsl] current-dateTime()

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

I said:

> XSLT supports a more specific run-time serialization. Let's have the
> following tree:
>
> <a>
>  <b>
>   <c>
>     <d/>
>   </c>
>  </b>
> </a>
>
> and templates tmpl-matchA, tmpl-matchB, tmpl-matchC, tmpl-matchD that
> match correspondingly the nodes a,b,c and d.
>
> Then it is true that:
>
> strtRunTime(tmpl-matchA) < strtRunTime(tmpl-matchB) <
> strtRunTime(tmpl-matchC) < strtRunTime(tmpl-matchD)
>


I missed to add that the transformation to be applied on this tree
consists exactly of these templates and nothing more.

To eliminate any correct but irrelevant to this topic responses, here
is a complete example. This transformation:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
  <xsl:output omit-xml-declaration="yes"/>

	<xsl:template match="a">
	  1
	  <xsl:apply-templates/>
	</xsl:template>
	
	<xsl:template match="b">
	  2
	  <xsl:apply-templates/>
	</xsl:template>
	
	<xsl:template match="c">
	  3
	  <xsl:apply-templates/>
	</xsl:template>
	
	<xsl:template match="d">
	  4
	  <xsl:apply-templates/>
	</xsl:template>
</xsl:stylesheet>

when applied on this tree:

<a>
 <b>
  <c>
    <d/>
  </c>
 </b>
</a>

produces this result:


	  1
	

	  2
	

	  3
	

	  4


Probably there would still be people saying that this does not prove
any ordering. Then modify slightly the code to this:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
  <xsl:output omit-xml-declaration="yes"/>

	<xsl:template match="a|b|c|d">
	  <xsl:param name="pTicks" select="1"/>
	  <xsl:value-of select="concat('Current node: ', name(), '; Tick: ',
$pTicks)"/>

                   <!-- Do Anything Here -->

	  <xsl:apply-templates>
	    <xsl:with-param name="pTicks" select="$pTicks+1"/>
	  </xsl:apply-templates>
	</xsl:template>
</xsl:stylesheet>

which produces:

Current node: a; Tick: 1
 Current node: b; Tick: 2
  Current node: c; Tick: 3
    Current node: d; Tick: 4



This basic example shows how one could typically specify actions to be
performed in strictly sequential manner in pure XSLT.

Do have a look at another example I provided not too long ago here:

http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200703/msg00436.html

It provides a general way to:

" write any XSLT transformation (the function f:transform) that will
have the ability to get the next "tick" (next consecutive sequence
number) at any time".





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







On Fri, Apr 18, 2008 at 5:55 AM, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
> As David Carlisle and John Snelson explained, in a pure functional
> programming language processing order is *generally* not guaranteed.
>
> However, there are well-known ways to manage the order of evaluation
> (monads or even more simply dependency between variables).
>
> In XSLT this is also valid. Lets have two xsl:variable-s:
>
>   $vX and $vY,
>
> such that $vY is defined as:
>  <xsl:variable name="$vY" select="f:someFun($vX)" as="someType"/>
>
>
> Then it is true that:
>
>   creationTime($vY) > creationTime($vX)
>
> Using this simple principle of dependency (causual) ordering, one can
> write code that is guaranteed to be evaluated in a certain sequential
> manner.
>
> XSLT supports a more specific run-time serialization. Let's have the
> following tree:
>
> <a>
>  <b>
>   <c>
>     <d/>
>   </c>
>  </b>
> </a>
>
> and templates tmpl-matchA, tmpl-matchB, tmpl-matchC, tmpl-matchD that
> match correspondingly the nodes a,b,c and d.
>
> Then it is true that:
>
> strtRunTime(tmpl-matchA) < strtRunTime(tmpl-matchB) <
> strtRunTime(tmpl-matchC) < strtRunTime(tmpl-matchD)
>
>
> Once we have thus given meaning to time and generally order in a FP
> environment, it makes sense to use this to our advantage in
> order-specific functions. Any such function that is provided in an
> external environment can be used (yes, we know this is
> processor-specific!) as an extension function.
>
> It is a good practice to wrap raw extension functions by
> <xsl:function>s. For example, doing so with FXSL one can make such
> functions higher order and can make it possible that they are
> partially evaluated (curried).
>
> Therefore, my advice would be to take an existing function, use the
> extension-function mechanisms available to access it as an extension
> function, then (if the function is useful and general enough) wrap it
> and make it accessible as part of a function library.
>
> Any suggestions for additions of such functions in FXSL are welcome.
>
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> You've achieved success in your field when you don't know whether what
> you're doing is work or play
>
>
> On Fri, Apr 18, 2008 at 4:54 AM, Andrew Welch <andrew.j.welch@xxxxxxxxx> wrote:
> > What is the reasoning behind defining as current-dateTime() and
> > current-time() as being "current at some time during the evaluation of
> > a query or transformation"?
> >
> > Saxon seems to follow the above and return the same value for each
> > call to the function, even during transformations that can last
> > several minutes (or hours or days).
> >
> > It would be really useful if it returned the actual dateTime at the
> > time of the call so you could implement a progress reporting feature
> > in the transform - you could say how many records were processed in a
> > given time and based on that suggest when the transform might finish.
> >
> > The spec does say it's implementation dependent, so I wonder why it's
> > fixed when people can do that themselves with a variable... if it
> > returns the time when it's called then it opens up quite a few
> > possibilities (especially where standalone transforms orchestrate the
> > entire processing)
> >
> > thanks
> > --
> > Andrew Welch
> > http://andrewjwelch.com
> > Kernow: http://kernowforsaxon.sf.net/
> >
> >
>



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