W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

Re: REST, uniformity and semantics

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 13 May 2003 13:08:40 -0700
Cc: www-ws-arch@w3.org
To: Walden Mathews <waldenm@optonline.net>
Message-Id: <B07D280C-857E-11D7-801B-000393A3327C@fla.fujitsu.com>

On Tuesday, May 13, 2003, at 11:13  AM, Walden Mathews wrote:

>> You must distinguish the abstract characteristics of description from
>> concrete specifications. I would argue that CORBA gives a similar kind
>> of descriptive power, at this level of abstraction, to SOAP/WSDL. 
>> (This
>> is not intended as a comparison, nor as an "I'm better than you" 
>> fight.)
> I can distinguish that a description of something is abstract from
> the thing itself.  Beyond that, you've lost me.  What's a "concrete
> specification"?

Well, I can say that the shape of a message needs to be described, and 
can even tell you roughly what it might mean to describe the shape of a 
message without saying that it has to be done in SOAP. SOAP is a 
concrete way of describing the shape of messages.

> And back to the subject of services and meanings, saying that
> interface descriptive power is central to the attainment of meaning
> seems like saying that people couldn't understand each other
> until dictionaries and language grammars were documented.  It
> seems false.  What exactly is your claim in this area?
>> Its possible to have a level 0 network with no common way of 
>> describing
>> the message traffic; e.g., email or IM. This work for email because 
>> its
>> intended for human eyes primarily.
> You seem to be going on the assumption that "describing message
> traffic" is somehow critical to the attainment of meaning, and then
> by logial extension, critical to the ability to provide service.

Well, a version of this yes. To fully understand a communication I need 
to know the alphabet, the vocabulary, the grammar, the semantics, the 
pragmatics, etc. In human conversation this is often pretty implicit 
(not always), but for machine-machine, especially when crossing 
ownership and trust boundaries, its essential.

That being said, there is still the `service on the back of an 
envelope' scenario that we are all obliged to consider. What that means 
is that the descriptions of the semantics of communications does not 
itself have to be formally machine processable; although there is 
considerable advantage if it is.

> Even if that were true, would it matter whether those descriptive
> things were happening in-band or out-of-band in your model?
> This is one of the ideas I resist.  A third party able to describe the
> messages I exchange with you and their meaning does not seem
> to constitute a level in our "stack".
>> If you are religious about REST and resources then you will see it 
>> that
>> way. ;-) However, again, I am trying to be abstract about it. Frankly,
>> I don't agree that seeing everything as resources solves all problems;
>> and I believe that I speak for many when I state that opinion.
> My previous comment was actually REST agnostic, but you missed
> that. ;-)
> The point, which I think you missed, was that constraining a language
> to talking only about resources isn't much of a constraint, given we're
> basically talking about data processing.

Well I do not agree on this point. I agree that resources is a powerful 
idea; but I do not agree that it is a `spanning idea'. Furthermore, I 
don't accept that Web services is `just data processing'.

>  Show me an RPC scheme and
> I'll show you how it's constrained to describing the manipulation of
> resources.

This is strictly beside the point. And this is why I (perhaps 
mistakenly) lumped you in with the RESTafarians. There has been an 
enormous amount of heat wasted on this topic during the course of this 

>> It doesn't have to be dependent on SOAP. The Web isn't. However, by
>> permitting this stratification, we could model REST on top of specs
>> like SOAP. That may not be the way that it works out in the end, but
>> there is a definite shift in interpretation/commitment going from
>> generic to specific in this way.
> I wonder what would be gained by modeling REST on top of
> specs like SOAP.  I wonder what would be lost.  But that's off
> the topic.
> So, in your model then, levels don't signify absolute dependency.
> That's in important revelation.

I am currently finding this analysis useful as a way of making sense of 
the different concepts floating around. It is not necessarily meant as 
an architecture.

>>> Example of the "bending" that is "required"?
>> What is it in the semantics of POST that captures the fact that a POST
>> to a particular place denotes a request for information in one case or
>> a request to update a bank balance in another or simply passing the
>> time of day in a third? That is the kind of bending I mean.
> I see the ambiguity of POST taken out of any specific context, but
> I don't see what's bent in this picture.  Or what you feel you have to
> bend.
>> It not completely mythical. There is a vast body of work around those
>> verbs; I didn't invent it from nothing.
> Is there a URL?

The verbs I mentioned are from the folklore of Intelligent agents, with 
special attention to speech act theory and communication languages such 
as FIPA ACL, KQML, etc.

See www.fipa.org, agents.umbc.edu, http://www-2.cs.cmu.edu/~softagents/ 
as starters on intelligent agents.

>  I had too many questions about this to stick even
> in a www-ws-arch email, and still do.  Such as
> - what makes you think this is not REST?

Speech act theory, and communications languages based on it, has some 
parallels with REST: the idea of a uniform interface for one. Where it 
parts company with REST is in seeing everything as a resource. Quite 
the contrary, speech act theory focuses on the intended meaning of the 
messages themselves rather than on some leaf node `resources'.

The basic idea is simple, if subtle: (this is not completely orthodox 
speech act theory)

Communication works because the participants agree that the purpose of 
communications technology is to communicate (as opposed to pretend, or 
lie for example).

Furthermore, the participants agree on a common language (actually its 
more like a meta-language).

Furthermore, communication is an example of action -- a speech action.

Then you have an analysis of speech actions into various categories: 
information, demand, commitment and so on. These categories are 
non-overlapping. An example of this can be seen in the difference when 
a third party is involved. If I tell you that the sky is blue, you can 
`forward' that to someone else with no loss of meaning. But if I tell 
you that you are promoted, that is not something that can be forwarded 
(what you can do is inform someone else that you have been promoted -- 
which is a different message).

This is way more detail than I intended. I am not trying to convince 
everyone to use speech act based communication; what I was doing was 
illustrating that there were many possible semantic commitments 
possible at `level 2' in my stratification.

> - how do you explain how this model accounts for action while REST 
> doesn't?
> Well, how about two questions for starters? (Three including this
> one, damn!;-)
>> The real message is this: (IMO) the real relationship between
>> messaging, Web services, REST etc. is the increasing amount of 
>> semantic
>> commitment being made.
> Semantic commitment?  I don't know how to interpret that
> phrase.

Semantic commitment means (sic) a pre-agreed interpretation of 
communication (say) exists -- one that is not itself encoded in the 
communicaton. Much like ASCII vs EBCDIC: the interpretation of a bit 
pattern depends on the external prior commitment to read it as ASCII or 
EBCDIC (or Unicode).

This applies at different levels; not just to bytes. A semantic 
commitment to a particular communications architecture can be `this is 
a mechanism for communicating about resources'. This would be a 
higher-level commitment than, say, `this is a mechanism for 
communicating DOM trees'; even if all the communications about 
resources involve XML.

Received on Tuesday, 13 May 2003 16:21:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:07 UTC