> From: Roger L. Costello [mailto:costello@m...] 
>
> 
> 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 
a verb.

(the latter sounds like hard-coding to me)

I'd rather see a classification of web services data based on speech act
theory. 

regards,
Bill de hOra