logo       

RE: Template recursion, StackOverflowError, saxon:while a nd variable assi: msg#00094

text.xml.saxon.help

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

I would be curious to see a sample data structure that illustrates the
problem.

Perhaps we can develop a solution that performs well but that doesn't need
extension functions. Then Mike could publish it somewhere as an example of
how to get around saxon:assign, so that he could then remove saxon:assign
when the time comes without abandoning any customers. I say "we" because
I'll be happy to help.

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)




"Willink, Ed" <Ed.Willink-usq10/2XDniZox4op4iWzw@xxxxxxxxxxxxxxxx>
Sent by: saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
06/16/2005 10:40 AM
Please respond to
saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx


To
"'saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx'"
<saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx>
cc

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






Hi Andre

...
> by a graph processing
...

Do you really mean graph or tree?

For a tree-structured problem one can envisage a very simple transform,
that declaratively takes in the entire data-base plus a change request
and returns the updated database. If the change request applies
to some low level branches, then multiple changes can be safely
executed in parallel on multiple processors. The XSLT compiler
needs to recognise the tunneling down to the branches idiom to
identify that the transform has a very controlled change domain
within which an assign rather than copy can be performed.

It then 'just' requires the XSLT compiler to manage the on-demand
re-distribution of data nodes to processors, so that you run one
massively parallel XSLT session rather than one per process.

If your problem is really a graph, then there must be significant
issues with determining the extent of the change, and more significantly
ensuring that the concurrent execution of 'assign'-optimised transforms
is deterministic. I don't think that XSLT as it stands, will allow for the
real life indeterminism that you currently have. You don't mind which
record is updated first, just so long as the updates are consistent.
But achieving this consistency probably means that you already have
a policy that constrains the potential graph anarchy, and this could
be exploited by XSLT to do what you do manually.

Regards

Ed Willink


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


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise