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

Re: Straw-man Proposal for our mission statement

From: Jim Hendler <hendler@cs.umd.edu>
Date: Mon, 12 May 2003 19:21:52 -0400
Message-Id: <p05200f0cbae5dc86c807@[10.0.1.2]>
To: Steve Ross-Talbot <steve@enigmatec.net>, public-ws-chor@w3.org

At 18:46 +0100 5/12/03, Steve Ross-Talbot wrote:
><x-flowed>
>Having seen Kick and Daniel's contributions and other comments, how
>does this sound:
>
>Mission Statement
>The mission of the W3C Web Services Choreography working group is to
>define a language complementary to WSDL such that a common view (global
>view) of business process interactions where roles and responsibilities
>are clearly defined in a way that is automatable for each participant,
>machine readable and in a manner whereby each participants involvement
>can be validated and such that the life cycle of those interactions may
>be short and/or long lived.

with due respect, there's some sort of problem in the above from a 
parsing viewpoint - there seems to be something dangling clause-wise, 
other than that, I like it, except I'm a bit puzzled on the 
"validated" part - what does it mean that an involvement can be 
validated -- if I buy a book from WebServ1 does that mean I can check 
to see if the book arrived?

>
>Focus
>Our focus will be that part of interaction that is externally visible
>as opposed to any internal private behaviour. Our aim is to capture
>this externally visible behaviour and to provide the means to compose
>web services or support the composition of new web services from
>existing web services such that these services can also provide an
>externally visible behavioural description, can participate in further
>composition and be validated against any subsequent interaction.
>

I like this

>Approach
>The approach that we intend to take is based on the capture of use
>cases reflecting our mission statement and our focus in parallel with
>CSF analysis to underpin the continued and  future business relevance
>of our efforts.
>

+1 here also

>Thanks to Daniel and Nick upon who's contributions I have drawn.
>
>Cheers
>
>Steve T
>
>
>On Friday, May 9, 2003, at 06:00  pm, Daniel_Austin@grainger.com wrote:
>
>>
>>  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.
>
></x-flowed>

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler
Received on Monday, 12 May 2003 19:22:03 GMT

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