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

[Ken Laskey <klaskey@mitre.org>]

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

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508