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

Received on Friday, 9 May 2003 12:59:39 UTC