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

[Mary McRae <mary.mcrae@oasis-open.org>]

Hi Jon,

  A Committe Note does not replace Committee Specification. That is still a very viable category, and there is no requirement that all Committee Specifications be submitted for OASIS Standard ballot. If what you're working on is a specification, then by all means it can stay in the Standards Track. The new Non-Standards Track is to support a formal process for approval of work products / documents that aren't specifications. The Non-Standards Track defines the approval level post public review as a Committee Note - the equivalent in TC approval terms to a Committee Specification.

  I hope that clarifies and alleviates your concerns.

Regards,

Mary


Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org 
web: www.oasis-open.org
twitter: @fiberartisan  #oasisopen
phone: 1.603.232.9090

Standards are like parachutes: they work best when they're open.



On Jan 10, 2010, at 11:35 AM, Jon Bosak wrote:

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