[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.? cheers, jeff > > 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]