Re: versioning at the Tech Plenary

KD>We address the topic of extension in SpecGL but we don't address 
KD>Versioning.
KD>Should we?

I've said this before, but now that other issues have been resolved
or at least been placed in a context, I can highlight aspects of the
context that would help to answer this question.

A. Up to now, SpecGL has been about best practices for writing a
   single document (spec) for a single version, presumably because we
   want to be able to measure the conformance of a single document.
B. Nonetheless, SpecGL suggests how the one document must relate to
   others: normative dependencies on other specs, deprecation as a
   way to transition from a prior version.
C. The recent debate about whether the spec needs to say something
   about unused DoV, to record the fact that the WG thought about all
   of them, would presumably apply to versions as well. We all agree
   that the WG should consider all the DoV, we just disagree about
   what form of statement will best satisfy the stakeholders. When it
   comes to versions, I don't think the WG would engage in all the
   work needed to define a new version unless there is a large body
   of unfinished business or new technology that has an impact, so
   the WG will certainly have thought about the differences from the
   prior version.

Surprisingly or not, KD's question breaks down into two:
1. What should a spec for version >1.0 say about its difference from
prior versions? This could be an area where SpecGL overlaps with
PubRules and/or the Manual of Style. SpecGL touches on this area
only with respect to deprecation.
2. What should any spec say about future versions? This is the area
of overlap with TAG.

My answer to (2) is that if the WG defines anything that is placed
in the spec to provide for future versions, they should elaborate on
that feature and its reasons. If SpecGL discusses best practices for
addressing future versions, it might give more guidance about what
such elaboration ought to convey to posterity.
.................David Marston

Received on Sunday, 19 December 2004 17:07:36 UTC