RE: Template recursion, StackOverflowError, saxon:while a nd variable assignability

Hi,

I had a quick look too and it is an elegant (though a bit complex) solution 
for rather simple cases (ex: a calculator variable) but relatively simple 
cases can find solutions easier than some complex real-life, high-demand 
situations and those worry me more than the simple cases.  For the simple 
reasons that, even though I highly value elegance, still a solution has to 
work efficiently.  If you have, as one of our customer has, 120,000 
customer companies running large business and management applications (ex: 
payroll) on a 24/7 portal, each client company with an average of 1000 
employees, and where each employee has to consult and update their data 
regularly, the required processing power is gigantic, and we have not 
accounted for visitors yet.  If every bit of information managed, and each 
access to it, has to be validated and secured by a graph processing 
application, in real-time, any small increase in the time it takes to check 
for security at a node will multiply billions of times and seriously push 
the processing requirements, possibly beyond a manageable server farm (ex: 
to more than a few thousand large SUN servers).  The point being that we 
should probably aim very high in looking for an alternative, targeting the 
complex real-life problems that can, do, and will occur, more than 
simplified model cases.

The calculator problem could be solved in different ways.  In similar, 
'simple' cases we simulate mutable variables just by using parameters and 
some recursion. In a case like this, one is not limited to using something 
like assign, and I would not.

Now we could ask if XSLT should be designed to support real-life, large 
scale, Web-based, high demand, graph processing applications?  I think so 
and I get the feeling that it must have been part of the plans for XSLT and 
Saxon.  Is it?  In any case, this type of applications is not going away 
and will probably increase substantially once tools and frameworks for them 
are fully available.  We feel that Saxon is a leader and a model.

Extracting the essence of the few use cases that we have for assign will 
take an effort and a bit of time but we will do it because the issue is 
important.  From there we will be in a better position to more closely 
evaluate alternatives and issues.

In the mean time, please maintain assign at least a little while longer.

Thank you.
Andre




08:47 2005-06-16, you wrote:
> > See also an example of "environment" that contains a set of
> > "variables", the values of which can be modified:
> >
> >
> > http://www.mulberrytech.com/Extreme/Proceedings/html/2003/Nova
> > tchev01/EML2003Novatchev01.html#t3.6
> >
>
> I've just taken the opportunity to re-read this excellent paper.
>
> This style of programming, where updating an environment involves copying
> the old environment using xsl:copy-of and appending a new name=value pair,
> should benefit greatly from the optimization introduced a couple of releases
> ago whereby xsl:copy-of creates a virtual copy of a tree rather than a real
> copy. This won't reduce the search time for getting the value of a
> particular variable in the store, but it will greatly reduce the copy time
> and the use of memory; and for an environment that only contains the
> (changing) value of one variable, this is what matters.
>
> The virtual copy is in essence just a pointer to the node that has been
> copied. The virtual nodes in the virtual copy are instantiated only when
> they are referenced, and themselves consist simply of pointers to the
> original nodes: they differ from the original nodes only in that they have
> different node identifiers (and thus a different position in document order)
> and that axes cannot navigate outside the subtree that was copied. A copy of
> a virtual copy is implemented as a virtual copy of the original, to avoid
> long chains of indirection.
>
> I would definitely recommend anyone who thinks they need saxon:assign to
> take a serious look at this solution.
>
> Michael Kay
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> saxon-help mailing list
> saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/saxon-help



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click