xsl-list
[Top] [All Lists]

Re: [xsl] current-dateTime()

2008-04-18 09:02:09
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(_at_)gmail(_dot_)com> 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(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> 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/

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--






-- 
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

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>