RE: suggestions for charter

[Peter Furniss <peter.furniss@choreology.com>]

Good - we are fully agreed.

Peter

> -----Original Message-----
> From: Greg Giles [mailto:ggiles@cisco.com]
> Sent: 28 March 2001 19:45
> To: Peter Furniss; bt-spec@lists.oasis-open.org
> Subject: RE: suggestions for charter
>
>
> 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
> > > >
> > >
> >
> >
>