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

I don't think you have added anything to your previous comments on this
subject and I don't think I can add anything to my previous replies. As I
mentioned before, I discussed this briefly with colleagues and none of us
considered that this needed to be raised as an issue against the
specification. You sent an example of the style of coding which you want to
use, and I found it easy to convert into the style which we consider
preferable because it is interoperable.

I find the argument that we "are limiting recursion" untenable. We are
indeed placing constraints on the structure of the application, but these
constraints do not limit your ability to use recursion. What they say is
that a stylesheet that produces multiple outputs must adhere to the same
constraints as an application that produces a single output: specifically,
the processing logic must be aligned with the output structure and not the
input structure.

It's true that the restriction was not present in earlier working drafts and
in vendor implementations. We introduced the restriction because it was
discovered that the facility as previously specified (or under-specified)
was not interoperable. 

When the time comes for last call comments you will have the opportunity to
raise this as a formal comment and you will then be entitled to a formal
reply from the working group, not just an informal one from me.

Regards,

Michael Kay


> -----Original Message-----
> From: Andre Cusson [mailto:ac@hyperbase.com] 
> Sent: 10 April 2003 04:58
> To: saxon-help@lists.sourceforge.net; public-qt-comments@w3.org
> Cc: michael.h.kay@ntlworld.com
> Subject: 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 Friday, 11 April 2003 05:35:42 UTC