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

Re: Hypermedia vs. data (long)

From: bhaugen <linkage@interaccess.com>
Date: Wed, 01 Jan 2003 10:31:40 -0600
To: www-ws-arch@w3.org
Message-id: <000d01c2b1b3$43ec09c0$b8eafea9@PC1>

Miles Sabin wrote:
> But the issue Mark seems unwilling to address is the fact that the
model
> stated this abstractly says nothing at all about the semantics of the
> application.

I don't see where SOAP says anything about semantics, either.

Nobody seems to be able to break out of this circular argument.

Don't know if I can either, but I have no big investment in either
REST or SOAP (although I can see big advantages in URIs
and hypermedia for application state, especially in
zero-config situations).

I've been working in four different groups that focus on business
semantics:  Bill McCarthy's REA community, ISO Open-EDI,
UN/CEFACT Business Process Work Groups, and some
speech-act groupies clustered around OpenebXML.

Most of those communities try to stay fairly independent of
particular implementations.  I've seen business semantic
models implemented in message-oriented SOAP (ebXML),
traditional EDI, distributed transaction processors (BTP),
and at least design ideas in REST.

Seems like there are at least two semantic problems:
* ontology, that is, the objects and relationships of discourse, and
* the semantics of interaction or conversation.

Here's two examples:
UN/ECE Recommended Electronic Commerce Agreement
(semantics of offer-acceptance, the most common
business conversational protocol)
http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf
(This is one of the bases of RosettaNet PIPs, UNCEFACT
Business Transaction Patterns and ebXML BPSS.)

From the speech-act gang, a combination of
ontology and semantics of conversation:
(assumes knowledge of UNCEFACT acronyms, sorry,
but mostly understandable by normal humans)
http://www.dsv.su.se/~prasad/Publications/WorkInProgress20021129BP2.pdf

I think both of those examples can be implemented
using either message-oriented SOAP or REST
or a transaction processor or probably other ways.

So I think the business semantic argument can be
taken off the table.  Not that either SOAP or REST
solves them, but that it's orthogonal.

If that's true, then what are the advantages and disadvantages
of each implementation? Or what are the situations where
one or the other would be more suitable? (Which might be
a more productive discussion...)

-Bob Haugen
Received on Wednesday, 1 January 2003 11:34:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT