[
Lists Home |
Date Index |
Thread Index
]
Essentially, you are just saying, "this is what the service does"
not "this is what the service will do when it receives this".
Unless the service itself is designed to cooperate based on
receiving a set of commands in one bundle (might be a useful
way to avoid reconnects), it's better just to send the type
of request by the names it publishes for that request.
For that, the URI is fine in the same way that as long
as it is only a name, it works for namespaces in XML.
But an assembly of them (this task AND now this task OR that task)
quickly turns into a mess because then one is well on their
way to sending a programming language. It is the evolution
of the piano roll to a midi sequence. Nice way to control
bots; business processes are not bots.
len
-----Original Message-----
From: Bill de hOra [mailto:dehora@eircom.net]
These sub-actions within data; sound like you're trying to describe a
service 'process' or a sequence of 'events', over that data, and
doing/embedding that in a data 'instance' might be awkward. Here's
another perspective on process, from Drew McDermott:
[[[
Suppose I described buying a Coke as a DAML-S
CompositeProcess, with two 'components',
PutInNickel and TakeOutCoke (if you find a
machine that behaves like this, let me know).
What I mean is that any instance of BuyACoke
consists of two parts, each of which is an
intance of PutInNickel and TakeOutCoke. But
you won't see any actual instances until you get
down to particular stories, i.e., particular
occasions when someone put in a nickel and got
out a Coke. It's a bit like programming-language
semantics, where one might define ";" by saying
"An event is of type "s1;s2" if and only if it
consists of two consecutive events, the first of
type s1 and the second of type s2."
]]]
The thread itself is an interesting one.
http://lists.w3.org/Archives/Public/www-ws/2001Nov/0008.html
|
