RE: suggestions for charter

[Greg Giles <ggiles@cisco.com>]

Peter, you captured the intent of my recommendation by saying "I certainly
agree there we can't include things in the specification just because it
looked like a convenient vehicle to sneak in something that is unnecessary
for the purpose of BT protocol."

Based on my original post "to ensure that each part of the specification
maps explicitly to a documented requirement" I think the problem is the
definition of 'part'. I agree that there will be 'parts' that explain or
clarify other 'parts', but we shouldn't have 'parts' that define the BTP
that don't map to a requirement. Also it is perfectly valid to have a single
definition map to one or many requirements, or a subset of those
requirements. The key is that a definition should map to at least one
requirement (or subset of that requirement).
In which case we could change my proposal to read "to ensure that each
definition within the specification maps explicitly to a documented
requirement".

As for the process we use if the rule is violated, it depends how we enforce
the rule. We can either formally review the spec and create a mapping table.
Or ask that this be considered when the spec is being constructed, in which
case the 'violation' could be raised to the sub-committee and a vote(?)
taken.

Greg
> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com]
> Sent: Wednesday, March 28, 2001 2:55 AM
> To: Greg Giles; bt-spec@lists.oasis-open.org
> Subject: RE: suggestions for charter
>
>
>
> Greg Giles sent:
> > Good start, I would also recommend we add:
> >
> > - to ensure that each part of the specification maps explicitly to a
> > documented requirement
> >
> > I think it's bettter to be explicit about this, rather than implicit.
>
> I'm not quite sure what you mean by this - or rather how the
> discussion goes
> when someone suggests a part violates the test. I certainly agree there we
> can't include things in the specification just because it looked like a
> convenient vehicle to sneak in something that is unnecessary for
> the purpose
> of BT protocol. But there will be parts  that are there to support or
> explain other parts, but which don't directly map to an original
> pre-stated
> requirement. Depending on the granularity of the requirement
> statements, I'd
> expect some of them to be fulfilled by the specification as a whole rather
> than a part.  Or do you mean the parts must have a justification, possibly
> written subsequent to the part.
>
> Peter
>
> >
> > My 2 cents
> > Greg
> > > -----Original Message-----
> > > From: James Tauber [mailto:jtauber@bowstreet.com]
> > > Sent: Tuesday, March 27, 2001 2:55 PM
> > > To: bt-spec@lists.oasis-open.org
> > > Subject: suggestions for charter
> > >
> > >
> > >
> > > I'd like to suggest the following points for consideration for the
> > > specification sub-committee charter:
> > >
> > > - to decide on document formats
> > > - to appoint editors
> > > - to gather material written by other groups (esp model and
> > messaging sub
> > > committees)
> > > - to make available draft specifications
> > > - to record feedback on draft specifications and pass on to
> other groups
> > > - to publish final specifications
> > > - to maintain errata
> > >
> > > Comments / suggestions / additions?
> > >
> > > James
> > >
> >
>
>