& XSLT >  > 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...

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.

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.


Cheers,
Dimitre

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

>  Dimitre Novatchev wrote:
>  
>    Hi
>  
>  > If in the context of memoisation we accept that "identity"
>  > is equivalent to all-memberwise identity of the items of
>  > the two sequences, then the effect of memoising long
>  > sequences arguments will be negative! It will actually be
>  > harmful!
>  
>    Good point.
>  
>  > I am proposing to leave developers the potential to define
>  > and implement sequence "identity" in the context of
>  > memoisation using other definitions (such as the
>  > reasonable comparison of a single "sequence-reference").
>  
>    Good idea.  Do you think to something like the following:
>  
>      <xsl:function name="...">
>        <xsl:param name="..."/>
>        <func:memoisation comparator="..."/>
>        ...
>      </xsl:function>
>  
>  where @comparator is a QName identifying a function (with
>  something like func:sequence-identity() to check identity of
>  two sequence, which is not implementable in plain XSLT or
>  XPath).  If yes, two questions:
>  
>      - what could be the default comparator?
>  
>      - does the arity of the comparator have to be always 2,
>        as it will be called once for each pair of argument,
>        or 2*(arity of the memoised function), as it will be
>        called only once for each memoised value?
>  
>  > 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.
>  
>  > This is the way to achieve maximum effect of memoisation
>  > without the harm (that would result for long sequence
>  > arguments) of imposing strict memberwise comparison.
>  
>  > Think of developers as often clever people that are
>  > capable of making the right decision in a particular
>  > situation.
>  
>    I completely agree.  Tools have to be designed to minimize
>  the possibility of writing bad things, default values have
>  to be well-choosed, but the developer always has to get the
>  ability to express what he wants.  IMHO.
>  
>    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