-----Original Message----- From: Dennis E. Hamilton [mailto:denn...@acm.org] Sent: Tue 5/5/2009 6:19 PM To: Hanssens Bart; oi...@lists.oasis-open.org Subject: RE: [oic] Discussion: Expanding Normative Sourcs and Prescription
Levels - Considering Authoritative Versions

Bart, I am assuming that we will want to keep the on-line availability of the materials, even though the authoritative version is always in a "document" (or package) in the OIC TC document repository. When the authoritative source (which may only be a working document) is just a packaging of the on-line materials that can be installed and used off-line, the same considerations apply to that material.

- Dennis

MORE THINKING ON THIS (this is requirements noodling and use-case visualization)

1. Granted the material on the wiki and the Subversion repository are never the authoritative ones, but some (ultimately most) of the material can be traced to the authoritative one that they are identified as reflecting, when they do so. When they are not authoritative materials, but working materials and other elements that have no authoritative connection, that should also be explicit and evident to inspection. Likewise, authoritative materials replicated (and unpackaged) on some off-line location need to link to their authoritative source and the potential for later revisions in some reliable way.

2. Since there are also materials in working versions and in various proposal and review states, it is valuable for people who explore the on-line locations (and any replicas that have been taken from the TC document collection) to be clear what the standing is of what they see. Finally, since there may be potential revisions of existing ones in various states, it is important to distinguish those from the ones they are proposed to revise, obsolete, or supplement.

3. Likewise, I do believe there will be iterations on the material, not only in working form but in the progression through document status (working draft, committee draft, committee specification) and there will be versions of all of those. OASIS requires new covers or the equivalent for the packages we make, and the files get different names and even locations, so there is more involved than toggling a status on the document descriptor in the OIC TC document set. That is, there is an extensive life-cycle of the materials we are producing and the forms we produce it in. Because these are aggregations of many parts, the parts need to be tied to their aggregation, because the parts are separable for use.

4. And finally, there needs to be a clear-enough identification that one can tell which specific (version) of test-assertions (sets) a particular test definition has been developed against.

5. This is all life-cycle management for something being iteratively and incrementally developed and intended for some sort of early and progressive usability. It seems to me that a very important aspect in the quality of our work is the traceability of what there is, what its status is, and what the interdependencies are. This is fine-grained for us (in contrast with, say producing a single specification for a version of ODF) and I believe our production of compilations that combine what we have at a given point in time will not remove the need to maintain the finer-grained relationships over the full life-cycle of the bits.