[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Occam's Razor
Alastair, I agree with your comments and the emphasis on getting a committee specification ratified and subsequently out into the market. My take from the call was that the TC members would all review the next version of the spec that Peter intimated would be distributed next week (the maximum you referred to). During the call it was suggested (by me) that the next version of the spec to be reviewed should be looked at, not only with the normal scrutiny on correctness and completeness, but also in terms of bringing it to the market(focussing on its simplicity/complexity, size/scope, and potential for adoption). I don't think anyone, including myself, is saying we MUST cut scope change direction or change decision that were voted on previously. During the call I was simply suggesting that as the spec comes together its a good idea to take a step back and revisit the goals and requirements for this spec, especially in light of the changing technology climate. This should also be done in conjunction with feedback from all parties that have spent time trying to promote BTP. Personally, my concern surrounds the barriers to adoption that we will face with the spec. We have all been emerged in this for months, yourself and Peter probably more that the rest of us, and I simply think at this point it is prudent to take a step back and make sure we are going to address the original problems and requirements we first defined. We also need to be aware of changes in the industry since we formed those requirements and scope. There has been a lot of progress in the areas of Web Services (WS), certainly the vision, application and direction of the core technologies and standards surrounding WS are evolving more clearly than before, and we need to be aware of this and react somewhat. Most importantly the spec needs to address the obvious pain points people are facing today and be careful not to deliver a behemoth of a spec that tries to cover every scenario and aspect of transactional business (and I am not saying that is where we are, but ebXML is starting to get some backlash because of this very problem). So having said all that, I think omitting informal specification material will not help lower the barriers to adoption but raise them. Perhaps splitting the spec into two documents, a Primer and the Spec would be etter - these are just thoughts but I think we should all take a look at the current version of spec ( the maximum ) and do as suggested on the call, in reviewing it on a broader scope than simply correctness and completeness. Regards, Mark Potts PS. ACRID brings to mind, other meanings including (harsh, sharp, unpleasant, bitter, choking), so while technically accurate, not sure about it? -----Original Message----- From: Alastair Green [mailto:alastair.green@choreology.com] Sent: Friday, October 05, 2001 10:31 AM To: OASIS BT TC Subject: Occam's Razor Dear colleagues, There is doubtless a spectrum of opinion in the BTP TC over the shape of the specification, given the phone call yesterday. 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. Nevertheless there appears to be a wide sentiment for such a revision. 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). Our chief concern is to get a committee specification adopted soon that can be got out into the market. 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. 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. Other companies might perhaps consider producing some kind of white paper to explain the context and purpose of BTP, which the TC could endorse. Yours, Alastair PS. ACRID should stand for Atomicity, Consistency, Reduced Isolation/Durability. It's a neat acronym.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC