Re: decoupling XSLT streaming recommendations from the main spec

Hi Michael,
   Thanks for the insightful thoughts.

I think that, personally I'm happy with both of following things about XSLT
3.0,

1) It's functional scope.

2) Streaming related recommendations.

I'm not suggesting in any way, to change or refactor XSLT 3.0 specification
in any way, to bring about new XSLT 3.0 spec.

But I'm suggesting to, have XSLT 4.0 come in two parts, say an XSLT 4.0
core (that can describe only XSLT's functional capabilities that doesn't
include streaming/performance related recommendations), and XSLT 4.0
streaming. I agree that, this refactoring of XSLT spec is not easy to do.
But the XSLT 4.0 work can spend longer time to achieve that. Till the time,
such an XSLT 4.0 spec comes to light, we'll have more time to absorb the
current XSLT 3.0 language.

On Fri, 23 Sep, 2022, 04:57 C. M. Sperberg-McQueen, <
cmsmcq@blackmesatech.com> wrote:

>
> It's hard to disagree with that.  But there are two reasons I probably
> am not thinking the same things you are thinking when I say I agree.
> They relate to the words "possible" and "improve".
>
> (1) What is possible for a group of forty people with ample support from
> their employers is not the same as what is possible for a much smaller
> group most of whom have not support from their employer for the work
> (and where the exceptions involve employers much smaller than, say,
> Microsoft or Oracle or IBM or Lucent or AT&T Bell Labs or most of the
> other organizations who dedicated people to the development of the QT
> specs).
>
> It is partly a question of the sheer amount of work involved --
> refactoring a set of documents is a non-trivial undertaking, and to be
> blunt I would be surprised if the community group turned out to have the
> necessary resources.  It is partly a question of the kind of changes to
> a spec that can successfully be made by a group that represents a
> relatively small slice of the larger community (on which see further
> below).
>
> So I suspect that what I think counts as "all possible means" may be
> relatively modest compared to what you may have in mind.
>
> (2) People may and do disagree over what counts as an improvement.
>
> Some time ago, like many other people interested in SGML, I spent a lot
> of time struggling to understand the SGML specification, which I found
> infuriatingly difficult to follow and understand.  I once suggested to
> an older and wiser colleague that the entire thing should be rewritten
> from scratch, as it could be made much, much clearer.  To my surprise,
> they disagreed firmly.  Suppose we had a completely rewritten spec.
> Users of the spec need to be certain that the new version is completely
> compatible with the old version in the ways that they care about -- how
> many years do you think would pass before those who have spent fifteen
> years trying to read and understand the old text could be persuaded that
> the new text meant exactly the same thing?  What would happen to all the
> other good things they could have been doing in the meantime?  Learning
> to read ISO 8879 may have been painful, but for key parts of the
> community it's a sunk cost.  Write books to make it easier for new
> people to understand, if you like, but don't rewrite the standard from
> scratch.  The same principle applied, they said, to XML Schema:
> rewriting it from scratch will satisfy some people and help others, but
> it will not benefit the community as a whole.
>
> Restructuring the specs by re-dividing them is not as drastic as
> throwing the existing spec out and rewriting from scratch, but it has
> many of the same risks and costs.  It would require a lot of work from
> some very smart people -- and I for one think the community will benefit
> more if those smart people focus on making better technology than on
> working hard to re-organize specs without unintentionally changing what
> they mean.
>
> So I don't think that for the XSLT community as a whole, a restructured
> set of specs necessarily counts as an improvement of the situation.
> Even if they are objectively speaking clearer and easier to read than
> the current specs (which is not a given, and will not be achieved
> easily), the cost of making a restructured set of specs would be very
> high, because it would divert some of the community's key resources away
> from more useful work.
>
> There is also a very serious question of community awareness and buy-in.
>
> When a small group working years later makes substantial changes to a
> design made by a much larger original design group, those substantial
> changes will often be viewed with some skepticism.
>
> As specs get older, the groups taking responsibility for them often get
> smaller and smaller.  There are some good reasons for this: those who
> wanted to work on the design of the spec have for the most part moved on
> because the work they were interested in has been completed.  But
> because the group is now smaller, it is possible for some changes to
> achieve consensus in the smaller group dedicated to maintenance that
> would never have achieved consensus in the larger group that created the
> spec.  If the group performing maintenance does not exercise a certain
> amount of self restraint, they can do damage to the spec.  I can think
> of examples where what the maintenance group described as routine
> clarification of edge cases were not in fact clarifications at all but
> were instead design changes with damaging long-term effects.  I suspect
> others can, too.
>
> Making changes that are too large is risky.  There is no bright line
> separating "small enough" from "too large", and opinions may differ.
> One thing to bear in mind is:  they may differ not only in the community
> group, but in the user community, and consensus in the community group
> does not necessarily mean consensus among the users of the spec.
>
>
>
> The end result of these thoughts is that I agree with you that the
> community group should do everything in its power to improve the XSLT
> spec and related specs.  And it is for that reason that I do not expect
> the CG to undertake to restructure the specs, and I will argue against
> the idea if it does come up.  I think I understand your point of view.
> But on questions like that, the ship sailed ten or more years ago.
>
> --
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com



--
Regards,
Mukul Gandhi

>
>