OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

On Jan 10, 2010, at 8:30 PM, Ken Laskey wrote:

> 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.
The different templates reflect substantive differences in the intent  
of the documents. Non-standards tracks docs are not expected to be  
treated as standards. OASIS won't and OASIS will encourage others not  
to. (But you can't completely control what others do.)
> 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?

I don't think so. Ken, since you are active in the w3c, consider the  
anbalagous differences between a W3C REC, W3C Note, and W3C Member  
Submission. The W3C positions them very differently. They have  
different intents, etc. although others have been known to treat them  
as all equivalent.
> 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?

A TC could do that if it wanted to - go back to a CD and start the  
entire approval process again -- but I can't imagine why a TC would  
want to re-approve a CS (which is an OASIS Final Deliverable) by  
"downgrading" it to a Note? After all, they must have had a reason for  
deciding to go do the Specification route to start with.

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

If by orphaned you mean the TC goes out of business and there is no  
one left to "maintain" a spec, this is pretty much orthogonal.

OTOH, I think because the expectations on Notes (non-standards track  
specs) there is less of an expectation wrt maintenance. Would really  
care if there is no one to "maintain" a presentation, a white paper, a  
discussion, a primer, etc.?


> 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

Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]