Re: decoupling XSLT streaming recommendations from the main spec

Mukul Gandhi <gandhi.mukul@gmail.com> writes:

> I'd hope sincerely that, the XSLT 4.0 effort shall, adopt all possible
> means to improve in any possible way the XSLT language's functional
> comprehension.

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

Received on Thursday, 22 September 2022 23:27:21 UTC