- From: bhaugen <linkage@interaccess.com>
- Date: Wed, 01 Jan 2003 10:31:40 -0600
- To: www-ws-arch@w3.org
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 UTC