- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Thu, 16 Aug 2001 19:27:02 -0700
- To: "Hugo Haas" <hugo@w3.org>, <xml-dist-app@w3.org>
We could but bindings may not be nestable without tweaking and nested bindings may not always expose all properties of the nested bindings. An example of the former is the SOAP attachment binding that when used in combination with the HTTP binding may force another media type simply because MIME multipart/related has another media type than a plain SOAP message. An example of the latter could be the RPC convention over SMTP not exposing the SMTP property of sending a one-way message. With a list comes also the need for a substantially more complicated negotiation mechanism: I can do A,B,C but not A,C along with the notion of figuring out which combinations are supported and what the exposed set of properties are. From a simplicity point of view, I would tend to say that knowing the set of available combinations and how they behave is not nearly as straight forward as knowing a list of URIs where somebody else has described the relationship to other bindings. Henrik >You consider a combination of bindings (e.g. SMTP+RPC) as a >new binding requiring a new identifier. > >Once people have come up with lots of different nested >bindings (attachments, RPC, maybe compression, etc), the >number of combinations will be fairly high, and a URI for each >of them might become unworkable. > >Presumably, the binding (and unbinding) of the SOAP message >will have to be an ordered operation: e.g. XML Infoset -> XML >serialization -> MIME multipart -> SMTP. > >What about an ordered list of URIs for a combination of bindings?
Received on Thursday, 16 August 2001 22:27:34 UTC