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: 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