- From: Mark Baker <distobj@acm.org>
- Date: Fri, 10 Oct 2003 09:09:00 -0400
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: www-ws@w3.org
On Fri, Oct 10, 2003 at 07:13:59AM -0400, Bijan Parsia wrote:
>
> On Friday, October 10, 2003, at 12:58 AM, Mark Baker wrote:
>
> > FWIW, using a RESTful approach to composition seems to simplify things
> > greatly.
>
> Perhaps, but it really is a non-starter for our next release. (Which is
> in a week or so :))
Ah, I didn't realize.
> > As each resource is a potential data source (via its state),
>
> I fail to see how that distinguishes this approach from any other. All
> process are a potential data source (via its state...*via*? Due do? I
> would have though that it's behavior counted too.)
I don't believe that behaviour counts, no, as it's the encapsulated
state of a resource that's provides the "data". Encapsulated state is
independent of any behaviour the resource exhibits.
Why I think this is important for simplifying descriptions of
compositions is because all resources are a source for a single data
stream. As Web services have unconstrained interfaces, one service can
provide many data streams, which complicates the identification of which
stream is intended to be used in any composition. Though it is possible
to treat a Web service as a resource (since they are 8-), Web services
architecture, as practiced, doesn't recognize this (otherwise we'd see
GET used more often).
> It seems to me you have a composition strategy ("containment
> relations") which may indeed be simpler wrt t dataflow (although,
> there's lots of simpler dataflow than what we're doing, but we're also
> trying to represent it more or less explicitly in enough detail to use
> a certain sort of reasoner about it...that's a slightly different task).
Interesting. Any pointers?
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Friday, 10 October 2003 09:04:53 UTC