Re: Dependence on works in progress

Michel Suignard wrote to <mailto:www-style@w3.org> on 21 March 2003 in "RE:
Dependence on works in progress"
(<mid:84DD35E3DD87D5489AC42A59926DABE901032DB0@WIN-MSG-10.wingroup.windeploy
.ntdev.microsoft.com>):

> This probably does not apply in this case. CSS3 line is far from being a
> Rec, and Unicode 4.0 will be a solid standard way before CSS3 line is
> itself a rec.

It was the Lists module that Chris mentioned, but your timeline seems just
as fair for Lists as for Line.

> Otherwise [Etan's] point is sensible

Actually, I'm having second thoughts.

Suppose that some Foo Organization maintains its specifications in the
manner of the W3C. A given version of a specification, at whatever maturity
level, is archived stably and for the long term.

Now suppose that Foo Organization ceases work on a specification that was in
a proposal stage. For whatever reasons, they have abandoned the work; this
does not make the work worthless. If the W3C still finds the work useful and
if reference to it is known to be stable, why shouldn't a W3C Recommendation
cite it, even normatively?

> There are many variants on the
> stability of a work in progress, and it would be a bad idea to ban them
> in principle ('should not' word is in RFC 2119 term pretty strong).

"Should not" means that exceptions can be made, but that they must be
justified. This level of restriction is just right for the situation. If a
mature specification maintains references to works in progress, the editors
of the former ought to be able to give a reason. A sufficient reason could
be that the work in progress is quite mature. A sufficient reason could be
that the reference is to a particular version that will not change even if
the work in progress is updated.

> I don't think I'd like to see too much policy developed in this domain
> and let WG and editors exercise their judgment in referencing other
> standards or work in progress.

I would feel more comfortable if the policy (using the amended "should not"
in place of "must not") were explicit as a mandate across the W3C. An
explicit policy is, at the least, a leverage point for people who raise the
issue of inappropriate references. One hopes that the policy would prevent
the problem altogether.

> It is nicely illustrated in the present
> case as Unicode 4.0 is for all practical purpose a done deal and it
> would be foolish to have the CSS3 rec reference an old version of the
> standard.

As you wrote before, Unicode 4.0 is set to mature before the relevant CSS3
module. So this case presents nothing special. By the time that the Lists
module is pending as a Recommendation, Unicode 4.0 will be published and the
reference will be rock-solid.

It would be a different story if the Lists module were now at the end of its
Proposed Recommendation review. In that case, my inclination would be to
postpone the advance to Recommendation until Unicode 4.0 reached finality.

After all, the ISO members are within their rights to reject the ballot for
ISO 10646. And if they do, Unicode is compromised. The chance is slim, sure,
but still existent. That would be a fine mess for any specification that was
counting on an affirmative outcome.

Received on Saturday, 22 March 2003 22:50:23 UTC