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

["Hanssens Bart" <Bart.Hanssens@fedict.be>]

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

Hi Dennis,


hmm, ok, although I think that in practice, the dependencies of assertions,
cases and documents will somehow reduce the number of possible combinations
of workflow states, and that there will be some natural order in what will
be approved when (for example: an "approved" test case pointing to a "draft"
test assertion doesn't make that much sense IMHO)

Now I don't have objections adding a "workflow-status" attribute or element,
but perhaps it would be easier if we just add the status and perhaps a version
number in the filename of every test assertions/cases/documents inside the
SVN, like we do with specifications (-wd, -cd for drafts etc) ?

That should be clear to anyone familiar with other OASIS deliverables and is
quite easy to do without any extra tooling.


Best regards,

Bart


-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Tue 5/5/2009 6:19 PM
To: Hanssens Bart; oic@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.