RE: [oic] Discussion: Expanding Normative Sourcs and Prescription Levels - Considering Authoritative Versions

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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.

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Monday, May 04, 2009 23:39
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: [oic] RE: Discussion: Expanding Normative Sourcs and Prescription
Levels - Considering Authoritative Versions

Hi Dennis,


> 5. I note, in this context, that the test assertions (sets) that we
> have so far are working documents (indeed, Bart's working documents),
> and that probably should be reflected in some sort of status element.
> (I note [shudder/cringe] that we probably could be making some Dublin
> Core elements in the XML of these sets, but I am not ready to suggest
> RDF or RDFa at this point.) 

Hmz, maybe I'm missing something here, but I'm not sure why we need this.

Suppose we do all our test work in a branch:
- when someone is more or less ok with his work, he annouces it on the
list or wiki
- we all take a shot at it :-)
- when we all agree on the work, it can be merged onto the trunk
- then we could run a script to zip *only* the trunk
- there will be other scripts, cases etc in the trunk that were
approved before, but that's ok
- this zip (with a date in the file name) could then go to the OASIS
document repository (IIRC, SVN doesn't count as approved work anyway)
- this zip will then be the draft version (as can be indicated by the
metadata field in the doc repository)
- at this point, it enters the normal approval flow we're all familiar
with
- since we all (or most of us) agreed on the work before putting it
into the doc repository, moving this forward to an approved work is a
formality
- we vote for it, and it (hopefully) becomes an approved work, so we
toggle the metadata field in the doc repository


Seems to align nicely with OASIS rules, without the need for additional
state metadata (but of course feel free to correct me)


Best regards,

Bart