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

[Marc Goodner <mgoodner@microsoft.com>]

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