[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] Issue 89
Bill, This is not, yet, an indication of my preference but there is a 4th option, which has been detailed at the inception of this thread; The debate, if nothing else has, shows a difference of opinion in terms of this feature being required, or understood well enough for inclusion in the 1.0 spec. This leads me to believe there is an option for closure of Issue 89 which would - Declare the issue/proposed feature as "not well understood" at this time and deferred to future work, i.e. out of scope for the 1.0 deadline. As a suggestion I think this vote is the first vote and then we move on to the three options you laid out, if appropriate. My point being that; 1) Delaying the spec for a month while we research debate this issue ( that could end up in us deciding to not include the feature / use case eventually) would do us no good at all (no added benefit to the delay) 2) Voting is not an option because I don't believe we have enough info to vote on 3) Delaying the vote is no different to option 1 in my mind. So can we vote on an issue not well defined? - you are right we cant - can we vote that we don't have the time to investigate and include this? - I think we could. So let me lay my cards on the table as to my thinking, at this time. The reason I don't think, again at this time, its right to add this to the 1.0 spec surround interoperability more than the feature being required or needed ( Geoff has a need ) whether the rest of the market will deem it required only the market will decide. I would add that I think, after the efforts of Geoff and Mark, I better understand this feature now and see some value but agree with Mark Little that the effort to bring this up to the level of the rest of the features captured and detailed in the spec is considerable amount of work. I will also return to well used SOAP box ( no pun intended ) in terms of the complexity of the spec, adding this feature whether it be optional or not will only complicate the spec and hinder peoples understanding and perception of what we are offering, solving. Back to my major concern - again after spending 2 days at the WS-I we identified over 70 "ambiguities", "optional features" "flexibility" through the SOAP 1.1, WSDL 1.x that have made interoperability between Web Services virtually unachievable. Their (WS-I) goal is to define a profile based on these specifications such that the ambiguities and options are defined in terms of "MUST". In BTP we have a single spec and my hope is that we do not create too many "MAY" "SHOULD" defined features facilities in the spec and end up in the same boat. When we discuss transition of state control and coordination responsibilities my concerns for the spec in terms of interoperability get even more pronounced. Regards, ------------------------------------------------- Mark Potts Chief Technology Officer Talking Blocks www.talkingblocks.com t. 415 395 9872 x2250 f. 415 395 9777 c. 415 606 9096 e. mailto:mark.potts@talkingblocks.com ------------------------------------------------- > -----Original Message----- > From: William Z Pope [mailto:zpope@pobox.com] > Sent: Tuesday, April 23, 2002 7:49 AM > To: OASIS BTP (Main List) > Subject: [business-transaction] Issue 89 > > > > Apologies to the participants but it is worth making visible to > a wider audience this point from email on the bt-spec list. > Paraphrasing from the ongoing conversation on Issue 89 ... > > We (the TC) need to spend more time discussing this before > voting on it. > > Which re-raises the issue that there is no guarantee we will > have made enough progress on this before the (self-imposed) > 1.0 deadline. In that case how do we proceed? Vote on what > may be insufficient knowledge, delay the spec, or postpone > the vote? > > I'm posing the question at this point so people can think about > it. We are not, quite, at the point where that decision must > be made but it's coming soon. > > William Z Pope > zpope@pobox.com > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > >
Attachment:
Mark Potts (E-mail).vcf
Description: text/vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC