[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