Hi
Mark,
Just
to clarify our position, we view the current spec draft as sufficient, perhaps
even a bit overly complex, and view the proposals for additional change as
adding to the complexity, and therefore not necessarily helping anything.
We have this view regardless of what was or was not previously
decided.
Thanks,
Eric
All,
I am
a little concerned about this. Firstly let me say I certainly can
understand some frustration, especially from those that have committed and
spent countless hours working on the spec to this point, surrounding
questions and concerns that make us revisit decisions already voted on and
agreed. However lets make sure we understand what was being discussed on
last weeks call (for those that were not present, or may have misinterpreted
the rationale behind the concerns). On the call there were some
people - me included - that expressed fears about the adoption of the
spec - I think having people raise these concerns was and is legitimate
and we need to discuss them. No one was saying we halt work on the spec
and certainly from my own perspective I don't want to do anything to
delay the spec publication. However a spec will not gain adoption if it
fails to gain consensus from peers, address a pain point customers are
facing or is simply too complex to be a viable solution for the majority of
problems being faced. On the call concerns were
raised, no actions items or vote proposals about descoping the
spec or writing user manuals were made, it was simply suggested that when
the next spec is reviewed we should also consider the complexity and barriers
to adoption that might or may not exist.
BTP
is open standards committee and the premise of OASIS is to get industry
together for formulate agreed upon specifications, while I share the concerns
of other members in delaying the publication of the spec - I also think its
essential that we review and look at the potential and barriers for
adoption - BTP will not be successful unless it gains adoption however
good the spec is, or however good the limited implementations are , and we
need to be mindful of this. I would say lets discuss this
matter - not over the next 2 weeks but on Thursday, canvas opinion, and
then we need to propose 1 or more courses of action that people can vote upon.
I don't think people are at opposite ends of the spectrum on this issue and I
would hate for this to blow out as an issue and cause rifts in the TC (
that certainly would not help adoption ) the TC members need to be in
agreement and be prepared to stand behind what we deliver as a spec, and the
more that do the better the potential adoption.
Just
as Mark Little pointed out in adding scope to the specification ( ala Sazi's
proposal ) the delay and complexity will hurt us, I think myself and one or
two others are simply suggesting that during the next review phase we consider
that exact same point in regard to the spec as a whole. On the opposite side
of that, I don't think that some of the decisions we have made at points in
time based should not be revisited, decisions have been made as we have
progressed based on the info and material available at the time, but that does
not mean there is never scope to revisit them and review them - I think
that is all people are were suggesting. I am a little confused, by
this formal proposal as some of those named were in agreement on the last call
that we should consider this point - anyhow lets discuss and hash this point
Thursday, but lets try and make it solution-oriented not
confrontational.
Regards,
-------------------------------------------------
Mark Potts
Chief Technology Officer
Talking Blocks
t. 415 255 7424
f. 415 255 7425
c. 415 606 9096
-------------------------------------------------
Given the discussions generated over the last few weeks about the
shape/content and future of any BTP specification, and the delays to any
attempts to adopt, we the undersigned wish to call a formal vote on the
following issue, to be resolved at the next teleconference on 11th of
October 2001:
The Technical Committee confirms the scope as determined by the
last San Jose face-to-face in late July and the subsequent quorate and
minuted teleconference of 16 August, namely:
To define the interoperable messages to be sent between
initiators and the factory, terminators and coordinators/composers,
enrollers and superiors, superiors and inferiors (including the roles and
responsibilities of sub-coordinators and sub-composers in a transaction
tree), and the relationship of contexts and replies to application messages,
plus facilities for recovery including message redirection, and compounding
capability to allow one-shot optimization and one-wire topology. A concrete
binding to SOAP and SOAP-with-attachments is included. Partial role-based
conformance is defined.
and further resolves to close discussion on issues of scope in
the interests of rapid adoption of the Committee Specification.
Mark Little (HP), Jim Webber (HP), Eric Newcomer (IONA), Pyounguk
Cho (IONA), Alex Ceponkus, Alastair Green (Choreology), Peter Furniss
(Choreology), Bill Pope, James Tauber (Bowstreet)
----------------------------------------------------------------------- SENDER
: Dr. Mark Little, Architect (Transactions), HP Arjuna Labs PHONE :
+44 191 206 4538, FAX : +44 207 670 1964 EMAIL : mark@arjuna.com | mark_little@hp.com
|