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

["Patil, Sanjay" <sanjay.patil@sap.com>]

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