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

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

Title: 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