Re: decoupling XSLT streaming recommendations from the main spec

Moving section 19 (Streamability) into a separate document would certainly be possible - it's perhaps 15% of the total document size - but it's not as easy as you might think, because of the need to ensure all the cross-document references are correct, the changes to the build scripts, etc, etc. And I'm not at all convinced of the benefits; it's not as if anyone is printing the specs these days. What the user community really needs to make the spec more accessible is more in the way of tutorials, for example a guide to the use of packages.

Doing anything more intricate to remove all mentions of streaming into a separate document would be far more work than I'm prepared to contemplate. It's also technically risky because it would be very hard to do the quality control to make sure no errors had been introduced in the process.

We do have a challenge in 4.0 of making sure that the streamability analysis covers new features of the language as well as old. For example, it has never covered arrays properly.

Michael Kay

> On 21 Sep 2022, at 11:13, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
> 
> Hi all,
>   I've been thinking about this since, a long time, and now I'm quite
> sure how I feel about this.
> 
> I think, the XSLT spec (taking ideas from XSLT 3.0) should remove
> streaming/performance related recommendations from the main body of
> the spec, and move that to a separate document (likely as a normative
> annexure of the main XSLT spec, or as a normative WG note linked from
> the main XSLT spec).
> 
> I feel that, having streaming/performance related recommendations
> specified within the main body of XSLT spec, is a major impediment for
> XSLT 3.0's adoption.
> 
> I feel that, this should be fixed as part of XSLT 4.0 efforts.
> 
> -- 
> Regards,
> Mukul Gandhi
>

Received on Wednesday, 21 September 2022 10:29:33 UTC