Subject: Re: [xsl] current-dateTime() From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> Date: Fri, 18 Apr 2008 05:55:07 -0700 |
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] current-dateTime(), Mukul Gandhi | Thread | Re: [xsl] current-dateTime(), Robert Koberg |
Re: [xsl] current-dateTime(), Mukul Gandhi | Date | Re: [xsl] current-dateTime(), Mukul Gandhi |
Month |