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