& XSLT Florent,

It is my fault assuming everyone is in the same context.

The *only* type of an xsl:function that can produce different results when
called twice with the same arguments is one that creates nodes -- with
instructions such as xsl:copy, xsl:copy-of, xsl:element, xsl:attribute,
..., etc.

Every time such a function is evaluated it will produce a new (different!)
node or sequence of nodes.


These functions are the only example of impure (having side effects)
xsl:function-s.

Therefore, I agree completely with Colin that the right thing is to
include in the spec a paragraph like this:

"Memoisation of an impure function (one that has side effects) will
generally have unpredictable results that conflict the semantics of such a
function. Doing so is illegal. As function impurity could be difficult to
ascertain, an implementation is not required to issue an error message for
specifying memoisation for an impure function and the sole responsibility
of doing so remains with the xslt programmer".


Cheers,
Dimitre 

--- Florent Georges <darkman_spam@[...].fr>  wrote:

>  Dimitre Novatchev wrote:
>  
>    Dimitre,
>  
>    I'm afraid I don't completely understand your response.  I
>  guess my poor English is the cause.
>  
>  > > > Also, developers could have a flexible definition, so that
>  > > > memberwise comparison could be used for sequences up to,
>  > > > let's say, ten items and reference (ID) comparison will be
>  > > > used for comparing longer sequences.  This treshold can
>  > > > even be determined dynamically depending on the speed of
>  > > > execution.
>  
>  > >   IMHO, it is a bad idea, as this could result in different
>  > > results when arguments are sequences of different size.  But
>  > > if it is needed, having the ability to set the comparator
>  > > let the developer the ability to get it.
>  
>  > I guess you and Colin are referring to "functions" that
>  > return newly-created nodes...
>  
>    Not only.  Actually, I though only about how to compare
>  arguments.  I don't see how this is related to the above
>  sentences (using different comparison functions when the
>  length of the sequences are short or not).
>  
>  > Let's put this straight in the specification and say that
>  > this is a "feature" of XSLT 2.0 of which developers/users
>  > must be warned and aware.
>  
>    What do you exactly mean by "this" ("this is a feature of
>  XSLT 2.0")?
>  
>  > I believe any attempt to memoise such functions correctly
>  > will have mixed results -- so, let's just warn the users
>  > and do the good thing for the real functions.
>  
>    I must admit I don't really see what you mean by "such
>  functions", "mixed results" and "real functions".
>  
>    Sorry for my bad undesrtanding of English, and thanks in
>  advance for any explanation.
>  
>    Regards,
>  
>  --drkm
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  	
>  
>  	
>  		
> 
___________________________________________________________________________
>  
>  Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son
>  interface révolutionnaire.
>  http://fr.mail.yahoo.com
>  


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
exslt mailing list
list@[...].org
http://www.exslt.org/list