RE: Issues summary (possibly to discuss on the call)

Ugo

See comments in line.

David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Wednesday, January 14, 2004 1:02 PM
To: Steve Ross-Talbot; public-ws-chor@w3.org
Subject: RE: Issues summary (possibly to discuss on the call)



> Bug 433: It might be useful to have a chor with no web services for
instance, a workflow
> if you don't take this into account, you can only use chor in a fully
automated system.

What about defining a Web service that acts as a proxy for the interaction
with a user? The request/response message would be, for example, some text
prompted to the user followed by an appropriately encoded user response. In
the case an HTML form is used, it's probably even possible to represent the
browser interaction directly using the WSDL HTTP Get & Post Binding.

<DB>Although this works, I don't really see how this is different from a
regular web service. After all Web Services are usually a "black box" in
that how the web service generates a response to a request is something the
sender of a request need not know. What might be more interesting is
including a service where the interaction with the user is done on the phone
...</DB>

> Bug 308: Reusable choreographies and data formats
> 
> can we (should we) define a language that is independant of actual data
formats
> and schemas (xml, pips, etc) and broader that just web services (e.g  mom)

The way this is formulated seems to imply that mom is incompatible with web
services. In effect a mom could be used as the web service transport
corresponding to a particular WSDL binding.

<DB>This is what Nick and I actually did in the WS Choreography Model.
Essentially the choreography definition is in two main parts:
a) A description of the flow in a way which names/identifies each component,
and
b) Definitions of the components identified.
The "definitions" can at their most abstract be just a URI and a
description. At their most concrete, conceptually they can be real
"physical" descriptions, i.e. including XML schemas, SOAP bindings, SOAP
extensions (e.g. security & reliability), end points for destinations of
messages, etc, etc.
However, although we have identified three levels: abstract, portable and
concrete, we have not (yet) defined what each level should contain.
</DB>
Ugo