I just got done reading the proposed revision and working my way
through the email threads, and Mary's response is a good lead-in to my
remaining questions.
1. Is there any substantive difference between a Committee Note and a
Committee Specification that a TC decides not to advance to an OASIS
Standard vote? I know the templates are different and this is
important to visually differentiate the two classes of documents, but
I don't consider the difference substantive.
2. In what way would a Committee Note indicate something different to
the world than a Committee Specification that isn't advanced.
Wouldn't it be simpler to designate specific wording to be included in
a Committee Spec status section to just say this document represents
one of the end products of the TC work?
3. How would we deal with the following scenario: a Committee Spec is
advanced to an OASIS Standard vote and fails. The template is changed
and the TC now deems it a Committee Note. Is this acceptable?
ALternatively, can Committee Notes just become dead ends if a TC runs
out of steam? Does having the designation of Committee Note improve
or degrade having orphaned Committee Specs?
Thanks,
Ken
On Jan 10, 2010, at 12:19 PM, Mary McRae wrote:
> 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
>>
>>
>
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
