OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [business-transaction] Email votes - 7 Issues - Ends Tues April 9-Conformance


I'm uncomfortable with this.  What I think we'd like to say is "if you do
something like this role, do it the btp way."  Bill's proposal (does his comment
make it something like a 'word horseshoe'?) goes part way.

What we're getting at is separability, but separating conformation from almost
conformant from non-conformant behavior is going to be ugly, messy, and turns
interoperation into an exponential testing exercise.  (or at least that's my
fear)

bill cox

William Z Pope wrote:

> Some suggested wordsmithing ...
>
>  An implementation may include multiple BTP roles, for instance
>  combining Terminator and Decider.  An implementation of a role may
>  be conformant while others in the same implementation are
>  non-conformant.  Such an implementation is conformant in respect of
>  the roles it does implement in accordance with this specification.
>
> =bill
>
> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com]
> Sent: Monday, April 08, 2002 7:06 PM
> To: zpope@pobox.com; Mark Little; OASIS BTP (Main List)
> Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> April 9
>
> Sounds good.  "Interoperable" was the word used in the text I evolved this
> from (see the change-marked version, 0.9.2.4), but actually non-conformant
> implementations can interoperate - with other appropriately behaving
> non-conformant implementations, so its a confusing use.
>
> Does making that paragraph say:
>
>  An implementation may implement the functionality of some roles in a
>  non-conformant manner - usually combining pairs of roles, such as
>  Terminator and Decider. Such an implementation is conformant in
>  respect of the roles it does implement in accordance with this
> specification.
>
> sufficient, or does it need some further minor surgery (amplifying or
> dropping the "usually ..." phrase ?) for clarity ?
>
> Peter
>
> > -----Original Message-----
> > From: William Z Pope [mailto:zpope@pobox.com]
> > Sent: 08 April 2002 17:31
> > To: Peter Furniss; Mark Little; OASIS BTP (Main List)
> > Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> > April 9
> >
> >
> >
> > I think you are both agreeing in concept.  This change is meant to say
> > that an instance may implement a BTP role A in a conforming way, implement
> > another BTP role B in a non-conforming way, and still be considered
> > conforming with respect to role A.  I think would be better to
> > use "conformant"
> > rather than "interoperable" because that's what this section is
> > talking about.
> > Using "interoperable" obscures the point.
> >
> > =bill
> >
> >
> > -----Original Message-----
> > From: Peter Furniss [mailto:peter.furniss@choreology.com]
> > Sent: Monday, April 08, 2002 10:14 AM
> > To: Mark Little; zpope@pobox.com; OASIS BTP (Main List)
> > Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> > April 9
> >
> >
> > > > --------------------------------------------------------------------
> > > >
> > > > Issue 87: Conformance Level
> > > >
> > > > --------------------
> > > > Proposed Resolution
> > > >
> > > > Change the second and third paragraphs of the conformance section to:
> > > >
> > > >     An implementation may implement the functionality of some
> > roles in a
> > > >     non-interoperable way - usually combining pairs of roles, such as
> > > >     Terminator and Decider. Such an implementation is conformant in
> > > respect of
> > > >     the roles it does implement in accordance with this specification.
> > >
> > > Isn't this a bad choice of words since we've always said that
> > > there are many
> > > roles in the specification, but they don't need to be played by a unique
> > > actor for each? Why should this affect conformance? An actor can (and
> > > should) be allowed to perform more than one role without affecting the
> > > conformance of an implementation.
> >
> > The paragraph was meant to mean that an implementation that, for example,
> > used a library approach, rather than a coordination hub server, was "fully
> > conformant" - avoiding the phrase "partial conformance". It is fully
> > conformant in what it does (assuming it does those things right),
> > and it is
> > nobody elses business how it does other things. It is a full
> > citizen in the
> > BTP world, as a Superior and Composer (say), even if the Factory cannot be
> > distinguished within it.
> >
> > I'd understood (and I hope the spec says) that an actor is approximately a
> > process (or perhaps an object instance - it's really defined by the
> > addressing), whereas an implementation is something you get on cd or
> > download. Within an implementation, once running, there may be
> > all sorts of
> > actors, or just one, and that is orthogonal to which roles those actors
> > perform.
> >
> >
> > Peter
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: william.cox.vcf
Description: Card for William Cox



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC