RE: [business-transaction] Issue 89

[Mark Potts <mark.potts@talkingblocks.com>]

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