W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: Straw-man Proposal for our mission statement

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Mon, 12 May 2003 13:49:57 +0100
To: <public-ws-chor@w3.org>
Message-ID: <005001c31884$fe44d760$f400a8c0@ENIGMAW07>

I have just been through the thread and notice that apart from Nick
there is no alternative suggestion to Daniel's initial input. I grant
you there is debate but I have yet to see alternative suggestions in
full.

I hope to have a stab at this today too. Given the call is tomorrow and
this is pretty important I think it makes useful agenda item. I'd like
more contributions to the debate so that we can move closer to a
consensus on a mission statement and then drive forward.

Cheers

Steve T

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of
Daniel_Austin@grainger.com
Sent: 09 May 2003 18:00
To: public-ws-chor@w3.org
Subject: Straw-man Proposal for our mission statement



Hi,

      Here is a proposed mission statement for our working group. This
is intended as a device to initiate discussion within the group. Our
mission statement is the first step toward our CSF analysis.

      Please keep in mind that this statement is subject to change based
on your input - it is by no means final or even close to what we will
end up with. It's only Daniel's $0.02.

      Let's start this conversation by looking at your Charter [1]. The
most relevant text I could find was this:

<our charter wording="creative-ambiguity-style>
The Web Services Choreography Working Group...is chartered to create the
definition of a choreography, language(s) for describing a choreography,
as well as the rules for composition of, and interaction among, such
choreographed Web services. </our charter>

      At first blush, we might think that this is a good candidate for a
mission statement. Modify the working a little and go...right?
Unfortunately, I don't think so, for these three reasons:
a) The text above makes a serious mistake in its direction to the group.
The problem is what I call "presupposing the solution" and it's very
common. Instead of posing a problem to be solved and saying "go forth
and solve this problem" the text doesn't bother to explain the problem
in any detail, but it tells us what the solution is already! This
artifact- and deliverable-centric approach isn't likely to produce a
good solution.

b) It's begging the question - do we really need Yet Another Markup
Language (YAML)? Sez who? To do what? What is the problem we want YAML
to solve? The world doesn't necessarily need YAML; it needs a solution
to the choreography problem, and while that may or may not result in
YAML, we don't need to constrain ourselves by thinking about the problem
in these terms. Not yet anyhow.

c) It's circular - apparently we need a choreography language to
choreograph Web Services. The logic isn't exactly clear.

      Based on this thinking, I decided that I'd like our mission
statement for this group to have the following features:
1) It must clearly set forth the problem to be solved, including an
indication of the overall scope of the problem.
2) It must not presuppose any solution in advance of the problem
analysis.
3) It must be clear and in the imperative case, so that a reader can
easily tell if the problem they have falls under our area of effort.
4) It must be contextually-driven, taking into account the current state
of affairs as we know it. When the charter was originally written, we
didn't know about the OASIS fiasco, for example, and our mission
certainly has to take these things into account if we intend to
accomplish our goals.
5) It has to be reasonable - the problem to be solved has to be scoped
in a way that allows us to actually have a fighting chance of success.

      Let's ask ourselves "What problem is it that we are trying to
solve?" If I had to put it simply, I would say that we want to solve the
problem of interoperability among Web Services and other systems. We
want all our Web Services to come home with report cards that say "plays
well with others". That's it. But that's a huge issue...and we cannot
(and aren't charged
with) solving the whole problem, just a part of it. Which part? The part
that concerns interactions between one or more Web Services and any
external systems. More specifically, we are concerned with the rules and
constraints that a Web Service has to follow in order to interoperate
reliably with the rest of the world. We can exclude the definitions of
the interface of any given Web Service - WSDL group is doing that. We
can also exclude questions of underlying low-level protocols, because we
want to leave this deliberately unspecified. The content and packaging
of Web Services messages are largely being handled by the SOAP WG. That
leaves us with a set of constraints on the sequencing (the ordering of
events in
time) and composition (the patterns of message and response among one or
more Web Services and one or more external systems, which may or may not
be other Web Services, human beings, non-Web Service services, or
something else altogether.

      So...after saying that, here is what I've come up with. YMMV.

<mission statement group = "ws-chor" type="CSF level 0">
The mission of the Web Services Choreography Working Group at W3C is to
specify the means by    which Web Services may collaborate with external
systems, specifically in the composition of multiple services and the
sequencing of messages among them. </mission statement>

Regards,

D-

*************************************************
Dr. Daniel Austin
Sr. Technical Architect / Architecture Team Lead
daniel_austin@notes.grainger.com <----- Note change! 847 793 5044 Visit
http://www.grainger.com

"If I get a little money, I buy books. If there is anything left over, I
buy clothing and food." -Erasmus


This email is confidential and may be protected by legal privilege. If
you are not the intended recipient,  please do not copy or disclose its
content but  delete the email and contact the sender immediately. Whilst
we run antivirus software on all internet emails we are not liable for
any loss or damage. The recipient is advised to run their own antivirus
software.



This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.
Received on Monday, 12 May 2003 08:50:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT