Re: [chairs] Draft Jan 2009 TC Process changes summary

[Jon Bosak <bosak@pinax.com>]

I don't have the energy to review the actual process language in
detail -- I'm willing to trust that the Board and Staff have done
the right thing -- so this comment is based on the summary.

As Ken Holman has observed, some of the UBL deliverables are not
intended for promotion to OASIS Standards.  For two recent
examples, see:

UBL 2 Guidelines for Customization, First Edition
    http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1prd03.doc

UBL 2.0 International Data Dictionary, Volume 1:
    Japanese, Italian, and Spanish
    http://docs.oasis-open.org/ubl/idd/UBL-2.0-idd.html

These have both been approved as Committee Specifications, which
in each case was the intended end state.  Under the revised
process (if I understand it correctly), these documents will in
the future undergo the same approval process but be known as
Committee Notes.  (I rather liked "Committee Specification"
because documents such as these are, in fact, specifications, and
the TC process as designed explicitly recognized a role for
Committee Specification as an end state; but if the Board feels
the need to specially identify specifications that are not
intended to be made OASIS Standards, I can certainly live with
Committee Note.)

Anthony Nadalin wrote:
 > Why not have a new document type below specification, I see this
 > as trying to force fit and will open TCs up to all sorts of
 > strange things that may not be appropriate

The category of Committee Specification was created in the first
place to allow TCs to issue documents that represented their
consensus effort as technical experts but were not necessarily
intended to be endorsed by OASIS as an organization.  A new
category below CS would be redundant.

Mason, Howard (UK) wrote:
 > I think this lower form of deliverable is exactly what
 > "Committee Note" is about.  It has no normative content, but
 > provides useful explanatory information about the implementation
 > of a specification or standard, and needs some form of agreement
 > process.  "Guideline" is too specific - "note" is OK.  I guess
 > the ISO equivalent would be a Technical Report.

I agree with almost all of this (and in fact would have preferred
"Technical Report" because that's already a known ISO label for
roughly the same thing, though I'm not passionate about it).  But
it should be understood that a specification that is not an OASIS
Standard can be normative if someone wants to declare it as such
within some particular context.  For example, the UBL Guidelines
for Customization could be declared to be normative if some
organization wished to use them in that way.  As noted in the
summary contained in the message that began this thread:

    Committee Notes ... are not intended to be normatively
    referenced by other standards (either inside or outside of
    OASIS), though of course there is no way to actually stop
    someone from doing so (hence the IPR safeguards and rigorous
    review/approval process).

The standards landscape is littered with specifications that were
never declared Standards but are used normatively.  Some IETF
Requests for Comment are good examples.  A particularly egregious
case is European Legislation Regulation M/715 2007 (Euro 5), which
mandates the implementation of a failed OASIS Committee Draft!
You never know the use to which these documents will be put, so
it's wise to require the same IPR policy and approval processes to
CNs that are applied to CSs.

Jon