Re: decoupling XSLT streaming recommendations from the main spec

Mukul Gandhi <gandhi.mukul@gmail.com> writes:
> 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.

Can you say a little more about how you came to that conclusion?

> I feel that, this should be fixed as part of XSLT 4.0 efforts.

In principle, maybe.

I’m always of two minds about these kind of changes. On the one hand,
they would often be an improvement, editorially[*]. On the other, it’s a
huge amount of work, far more than it appears at a casual glance because
of all the references (explicit and implicit) that would have to be
managed. And it may introduce new errors. And, in the end, the benefits
are difficult to quantify.

It might be more approachable for some readers, but if that’s a
significant number of readers, we’d have to believe that a significant
number of readers approach the XSLT 3.0 specification, are entirely
comfortable until they get to chapter 18, then give up because they
can’t ignore that optional feature, but that these readers *wouldn’t*
give up if chapter 18 was a separate document. I’m unconvinced.

The rewrite doesn’t help implementors at all, really, because if they’re
going to implement streaming they have to do it all anyway, and if they
aren’t, surely implementors can look past chapter 18.

If the XSLT specifications were maintained by a paid staff whose full
time job was writing them, I’d totally support paying them to do the
editorial work you suggest. But in as much as they are volunteers and
the amount of time they can devote to the effort is limited, I’m not
sure I could be persuaded that its the best use of their time.

                                        Be seeing you,
                                          norm

[*] I’d love, for example, to go back and rework XML, XML Namespaces,
XML Base, XInclude, and xml:ID into a single, editorially unified
whole.

--
Norm Tovey-Walsh
Saxonica