[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
In answer to question 1. > 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? In TAG TC we have written a guidelines document whose style is not really suitable as a technical specification because it centres around examples, explanations and suggested best practises. This does not mean we could not use the Committee Specification template but doing so does leave room for confusion. But it is not so much the template (and its boilerplate text) but the whole style of the prose of the document which makes it more of a committee note than a committee specification. It is written like a tutorial for those wishing to understand the technology rather than as a specification. A Committee Note document type (whatever its name) might have been ideal for this document. I note too that it does not follow that it would be a document having any realtionship to any document intended as a Standard; it could be standalone (though in this case it does act as guidelines to other documents we wish to pu on the Standards track). Best regards Stephen D Green Editor/Secretary, Test Assertions Guidelines TC 2010/1/11 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 > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]