[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Fwd: Occam's Razor] on behalf of MCL (HP)
On behalf of Mark Little, who is having a problem getting mail onto the list. Alastair
- From: "Mark Little" <mark_little@hp.com>
- To: "Alastair Green" <alastair.green@choreology.com>,"OASIS BT TC" <business-transaction@lists.oasis-open.org>
- Date: Mon, 8 Oct 2001 10:51:39 -0000
> To us it seems unhelpful, at this late stage, to seek to revise the > overall shape and scope decided upon in the San Jose meeting, and (at > BEA's instigation) expanded to include VCT-composer relations, also > officially decided at a teleconference in August. I agree. The more we cut out, the more diversification in the implementations there will be and the less useful BTP will be. This is not the time to rewrite the specification. I hate to say this, but if people are unhappy with the specification as it currently stands then it's too late to modify it. Much of the specification has been as it currently is for many months, especially as it relates to some of the current "issues". Vote against it's adoption if you think that it is not what you want, but we should not be considering modifications to it now. > Nevertheless there appears to be a wide sentiment for such a revision. I don't think it's as wide as you might think. > The last thing any of us need is a sprawling, eight-way debate on what > stays in and what stays out. The maximum edition (which gives a > coherent, overall picture) would have been useful, and so will a minimum > edition (which gives a stripped down but technically accurate atomic > two-phase coordination protocol). "would have been useful" should be "is useful" IMO. If people want a "management view" of things, or a "white paper" equivalent which just gives an overview, then someone else should edit that and provide it as an introduction to the specification. > > Our chief concern is to get a committee specification adopted soon that > can be got out into the market. Agreed, and as of the last face-to-face I thought we had reached agreement on the look-and-feel of the specification. In fact, I'm pretty sure we voted on it. > > We are therefore preparing a new submission to the TC. This will consist > of a draft specification 1.0 which will contain the bare minimum > required for a technically correct specification of interoperation > between Superiors and Inferiors, and will entirely omit any informal > explanatory material and any attempt to set this core relationship in > the context of cohesions, transaction trees, etc. What makes BTP different is the relaxation of ACID, and the *standardisation* of this. If we are now to lose this, then HP will have to seriously consider whether it is worth continuing involvement. A "loose and woolly" specification that has "may", "can", "should" or plain and simple doesn't say, will mean that users can be tied to vendor implementations quite easily. Now perhaps that's what some members of the BTP committee want, but it's certainly not what HP wants. > This submission will be available at some point prior to next week's > phone call. > > At that point we will leave it in the hands of the TC as to how to > proceed. Of course Peter is prepared to remain as co-chair of the > specification committee to help administer the process of bringing the > spec out. Our writing capacity will have to be limited to revising or > perfecting those parts of the minimal spec that we consider core and > vital, including ensuring that the XML encoding/SOAP binding is adequate > for a realistic Web Services environment. I'd just like to say many thanks for your continued efforts in trying to produce the specification. > > Other companies might perhaps consider producing some kind of white > paper to explain the context and purpose of BTP, which the TC could > endorse. I think if we want multiple versions of the specification then other people should take on that effort. However, the version of the specification we agreed on at the last face-to-face should be the one we vote on. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203
begin:vcard n:Green;Alastair tel;cell:+44 795 841 2107 tel;fax:+44 207 670 1785 tel;work:+44 207 670 1780 x-mozilla-html:FALSE url:www.choreology.com org:Choreology Ltd version:2.1 email;internet:alastair.green@choreology.com title:Managing Director adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX; fn:Alastair Green end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC