RE: Choreography and REST

> -----Original Message-----
> From: Mark Baker [mailto:[email protected]]
> Sent: Friday, August 09, 2002 3:51 PM
> To: Christopher B Ferris
> Cc: [email protected]
> Subject: Re: Choreography and REST
> 
> 
> I'd encourage you to take some time to consider exactly how you might
> form a solution to this (or any other) problem within the 
> constraints of
> REST.  If, after you've done that, you've decided it isn't 
> suitable for
> your needs, then by all means don't use it.

[speaking as a WG member, not as a co-chair]

I'm having a little trouble following what the Choreography proposal does or
does not have to do with REST.  It seems to be a declarative language for
specifying, a priori, the message patterns required to implement a
relatively complex set of web services transactions.  It's layered on SOAP
and WSDL, so to whatever extent SOAP and WSDL support REST, the Choreography
proposal supports REST.  Chris gave quite a clear explanation of why this
kind of thing is useful.

What have I missed up to this point?  

Paul Prescod seemed to be making a couple of points that I picked up on.
First, the *implementation* of a "choreographed" web service could be done
effectively with a shared "state" resource, perhaps analogous to a file
handle in programming languages.  Second, he seemed to be saying that one
wouldn't need a special choreography language *if* one already had a
RDF/DAML-based language for declaring the semantics of business processes. I
think I agree ... but the trouble is we don't have such a thing, or at least
the people making the Choreography submission (not to mention the BPEL4WS
folks!) don't seem to believe we do. 

I found Paul's discussion of using REST principles to coordinate multi-part
web services quite persuasive, but the rest of his (and this) discussion
seems to be more about specialized choreography/coordination languages vs
generalized semantic description languages, not about REST per se.  Again,
have I missed some important point?