[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary
I think the template for work products quality should enumerate only the must-have sections. Currently conformance clauses are listed as may-have for the Non-Standards Track work products. I think this clause (item 2.18-B-1) should simply be removed. > -----Original Message----- > From: Marc Goodner [mailto:mgoodner@microsoft.com] > Sent: Monday, Jan 11, 2010 12:56 PM > To: Patil, Sanjay; Peter F Brown (Pensive); Jon Bosak; Mary McRae > Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org > Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary > > These draft changes include conformance clauses as allowed work product > for committee notes. If these are truly informative materials > conformance clauses don't have a place in them and they should not be > listed as an allowed work product. > > -----Original Message----- > From: Patil, Sanjay [mailto:sanjay.patil@sap.com] > Sent: Monday, January 11, 2010 12:37 PM > To: Peter F Brown (Pensive); Jon Bosak; Mary McRae > Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org > Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary > > > +1 > I think the debate and decision of what qualifies as a normative > specification vs. other/informative material should be left up to the > TCs. > > I would also like to voice an opinion in favor of the TC process > changes for supporting creation of Committee Notes. I think the Service > Component Architecture TCs potentially could use this option for > publishing the material related to testing of the specifications. > > -- Sanjay > > > -----Original Message----- > > From: Peter F Brown (Pensive) [mailto:Peter@pensive.eu] > > Sent: Sunday, Jan 10, 2010 19:01 PM > > To: Jon Bosak; Mary McRae > > Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org > > Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary > > > > I think that we avoid should semantic discussions about the meaning > of > > "spec", "information note", "guidelines", etc and concentrate on > > establishing a clear distinction between what a TC *intends* to be > > normative (and thus establish a legitimate expectation on the part of > > "consumers") and what a TC intends *not* to be normative (and thus > > effectively issuing a caveat emptor). > > > > What the current discussion seems to boil down to is thus a matter of > > intent. > > > > The only thing "we" (any OASIS TC or authority, as the "producer" of > a > > work) can have any control over is whether a work is intended as a > > normative work or an informative (or any other purpose) sort of work. > > > > I agree with Jon that there will be many authorities who will wish to > > make normative use of potentially *any* OASIS TC work but we can > never > > predict, manage or control that. No TC, nor OASIS itself, will be > able > > to address the issue of intent on the part of the "consumer". > > > > Best regards, > > Peter > > > > -----Original Message----- > > From: Jon Bosak [mailto:bosak@pinax.com] > > Sent: 10 January 2010 11:21 > > To: Mary McRae > > Cc: Jeff Mischkinsky; chairs@lists.oasis-open.org > > Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary > > > > 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. > > > > Actually, I got that. Sorry if it sounded like I didn't. > > > > What I meant was that the ordinary English meaning of the word > > "specification," viz., "a specific, explicit, or detailed mention, > > enumeration, or statement of something," applies to a lot of things > > that we're going to be calling Notes. For example, the UBL > Guidelines > > for Customization constitute "a specific, explicit, detailed mention, > > enumeration, and statement" of our guidelines for customization. The > > document is a specification of our guidelines. The new use of > > Committee Specification now limits the universe of things called > > specifications to those specifications whose possible end point is an > > OASIS Standard. That's OK, but it is a limitation on the plain > > English meaning of the word. > > > > This is just a terminological observation -- not worth quibbling > > about. > > > > Jon > > > > > 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 > > >> > > >> > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]