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


> 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