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

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

I support the following ideas:

1. Having <ta:NormativeSource> values for different sources of conformance
interpretations, interoperability guidelines, and discretionary tolerances,
depending on how we package the OIC TC "products."  I submit that for ODF
1.1 (and probably ODF 1.2) there will be very few *direct* references to
normative statements in the OASIS specifications.  I think that we will
indeed need to go "indirect" in many of the test assertions.

2. Having more flavors of <ta:PrescriptionLevel> to reflect the cases beyond
strict conformance and optionality (depending on the normative source,
etc.).

I want to raise some other matters I have been noticing and mulling over on
this general theme:

3. I think it is time to step back and look at the prescription levels and
normative sources and how we will correlate the test assertions (sets) to
descriptive material.  We need some way to cross-reference in a reliable way
among the test assertions, descriptive materials (OIC-produced
specifications), and OASIS Standard specifications (and other standards, for
that matter).  There also needs to be a way for (metadata of) test elements
to lead back to the test assertions (sets) which they exercise and a way to
index the test elements by test assertion (set).

4. Finally, it is time to think about how we version and level the
test-assertions (sets) and maintain provenance and authority between on-line
materials and the official OIC TC documents that are the authoritative
sources, when they exist.  It is also important to be able to version these
and their status since that will matter as the authoritative documents are
moved through various stages and the test assertions (sets) themselves are
revised, obsoleted, etc.

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.)  I don't think they need versions although dates on the individual
ones would be useful. (I note that the Subversion $Id$ label and other
automatic labelings are not useful for content accessed directly on the
Subversion repository itself, so an explicit date is required.) 

6. Finally, we need some namespaces and/or DTDs for the XML forms that we
are working with (and those will probably be versioned too).

I am sure that a great deal of discussion and exchange of ideas will be
involved in order to converge on a set of practices in this area.  We will
also have to be attentive to the OASIS TC Procedures and how authoritative
materials are established, preserved, and kept available.

 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 


-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200905/msg00004.html
Sent: Monday, May 04, 2009 04:09
To: oic@lists.oasis-open.org
Subject: RE: [oic] Version Control Commit by bart.hanssens

[ ... ]


As Dennis pointed out, my assertions are mostly interpretations on how
an implementation IMHO should implement the ODF specification, instead
of conformance clauses for documents (taken from the spec itself)


As Rob pointed out, we can actually do this as the OIC TC and I strongly
feel we should (we could call it an Interoperability Profile, whatever)
since the spec is 

a) rather vague (or silent) on implementation behavior
b) the document part is mostly covered by the XSD

[ ... ]


Now, putting "interpretation" in <prescriptionlevel> isn't the cleanest
solution, but from a practical view, it saves one level of indirection:

- if I had to point from <normativereference> to yet another (yet to be
written document) called "ODF interpretation", and then point from that
document to the part of existing ODF spec...

- anyway, the assertion files being XML, we can simply write a script to
extract said "ODF interpretation" document afterwards



Best regards,

Bart


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php