Re: [saxon] RE: result-document from a temporary tree

Hi,

We are writing this in desperation, I guess.  We have looked at this from 
many angles, time after time, and can not find any other good solution for 
the problem that we are having with the new constraint that the WG has set 
for XSLT 2.0.  A major change from the version 1.1 draft and from the 
current production version of Saxon (v6.5.x).

By preventing result-document from being invoked from a temporary tree, for 
the benefit of saving unconscious programmers for checking the validity of 
a variable or parameter (by limiting side-effects), the WG and Saxon 7.x, 
are limiting recursion which is a fundamental tool in tree processing.  The 
added processing and maintenance weight of any alternative approach, to our 
current application is simply frightening. Moreover, the simple and natural 
approach that we are using (Saxon v6.5.2) provides clearer and more 
efficient logic than any alternative, for the problems at hand.  And there 
are quite a few of those too and that is because the logic is 
natural.  Many problems may be better solved other ways but some really 
basic ones are better served this way.

It seems to us a very small thing to fix in an otherwise great 
standard.  This fix would return a lot of power for a very small price 
(especially if good documentation is available to guide new programmers 
(and since other issues may still force him/her to put a "check in the 
code" anyway) ).  One error report less in the standard and one condition 
less in Saxon 7.x.  That is all that is required.  Would anyone like to 
better understand what this is costing us ?

Preventing efficient recursive processing in pull technology not only 
limits the language power and expressiveness but it makes it non-orthogonal 
where some things can be done in push but not in pull. Unless you use 
iteration instead of recursion (and change the logic to something 
unmanageable and lethargic) or unless you split the logic, add large 
overhead (100s of additional templates) and use pseudo higher-order 
functions in XSLT or unless you try to redesign the problem, the data and 
the application to use push technology instead, as efficiently and without 
calling result-document from a temporary tree.

Invoking result-document from a temporary tree is very useful, efficient 
and clean for a family of natural problems.  Like others in XSLT, it is a 
powerful feature when used appropriately.  It also fits in a very natural 
logic process in functional programming. It is a feature that has been a 
part of programming for a very long time.  As a matter of fact, it was part 
of XSLT1.1 and Saxon and EXSLT...

In a world where output is often to web pages, output has to be broken into 
page files.  That is why you have result-document. Web pages have 
hyper-links and other links to assets and other files.  Web pages are graph 
nodes that are mapped to files.  They have to be generated and processed as 
nodes in recursive tree structures.  So why block recursion for them 
?  Isn't this what this language is designed for in the first place ?

Please reconsider this un-useful constraint and ensure an optimal standard
and a flexible and supportive (Saxon) transformation processor.

Do not hesitate to contact me as you feel
or if you think that we can help.

Thank you.
Regards,

Andre Cusson, cio
ac@hyperbase.com
01 Communications Inc.




>At 01:39 PM 3/10/2003 +0000, you wrote:
>
>I had a word with my colleagues on the WG about this (though not on the
>official agenda) and could find little support for relaxing the current
>rule. There was a general feeling that outputting a result document
>while producing a temporary tree is a side-effect and should not be
>allowed; also that it should be possible to achieve the required effect
>without doing this.
>
>Michael Kay

Received on Wednesday, 9 April 2003 23:34:29 UTC