Lists Home |
Date Index |
> From: Roger L. Costello [mailto:firstname.lastname@example.org]
> This XML message is identical to the earlier XML message
> except for the root element. The root element implies
> action. The root element is directly correlated to a method
> name. Its child elements are the parameters.
The difference I can see is not that the root element has a different
name, that a human might reasonably interpret by default as a verb. It
is that in the second case the _emitting_ software understands the root
element as a verb, not a noun. Changing tags doesn't make data
action-oriented, invoking code with that data does.
> I contend that this action-oriented root element gives the
> message a very different feel. I contend that it tightly
> couples the message to a particular kind of service - one
> that returns flight information. The data-oriented approach,
> on the other hand, is not coupled to any service, so it could
> be used by a variety of services.
The tightness in your examples are in any assumptions the *emitting*
software is making about what will be done to its data. i.e. how that
data will be acted on. Either way it's emitting data, passing a message,
uttering, or whatever. Tight coupling comes from faking a single thread
of execution on a network, not enough indirection, and hard coding
assumptions in software about what other software should be doing.
The distinction I do see between action and data is this:
-data: the emitter doesn't assume how the message
is to be processed.
-action: the emitter assumes the message will
be processed according to its understanding of
(the latter sounds like hard-coding to me)
I'd rather see a classification of web services data based on speech act
Bill de hOra