On 23.02.2007, at 19:46, Glen Daniels wrote: > > Hi Jan, all: > > Jan wrote: >> So, is this an order? >> >> receiver.cancel( >> >> <ns:order xmls:ns="[xsd-target-namespace]> >> <item1>...</item1> >> <item2>...</item2> >> <item3>...</item3> >> <shippingAddress>...</shippingAddress> >> <billingAddress>...</billingAddress> >> </ns:order> >> ) >> >> >> >> >> And how would you ever be sure that cancel() had the same >> semantics by the time you invoke it as it had when you read >> the WSDL? > > The same way you're sure that POSTing "<cancel>" to > http://RESTsvc.com/PO5432 has the same semantics as it had when you > read > the... um, I guess the human-readable web page describing the purchase > order setup and semantics at RESTsvc.com?
Another issue here: in a truely RESTful system, this would violate message self descriptiveness, because you need a form of standardized agreement and not a 'web page describing...'. It is not the communication peer that is to define the payload semantics, that must be handled by standard bodies. Of course, this approach is open to evolution. A payload definition might originate from one single service supplier and if it is good, it might gradually be adopted and become a de-facto standard and a real standard in the long run. The further this process goes, the more valuable the overall system becomes (Flash is IMHO a good example of this in the human-Web world). The term 'standards body' is (IMO) much more about wide spread support and agreement as it is about making your way through IETF or ISO or whatever. (In fact quite often standard bodies only carve in stone some minimal set of commonalities from what has been growing in the wold for some time (see the C proramming language or HTML as examples). Jan > Is that any different, > really?
