- From: <Noah_Mendelsohn@lotus.com>
- Date: Fri, 29 Jun 2001 20:13:37 -0400
- To: "Mark Nottingham" <mnot@mnot.net>
- Cc: xml-dist-app@w3.org
Overall, I like this a lot. Thank you. I suspect we will want to play around with layout and typography, perhaps doing some form of tables, but that can come later. A few other comments: I think we need to follow through on some other implications for this to be coherent. Specifically, because this addresses only the abstract Envelope section, a naive reader might wonder where the <...> went. After all, most SOAP messages we've seen actually do have <..>. I think many of us agree that the answer will be found when we describe the way bindings work: any SOAP envelope Infoset necessarily has a representation as serialized, well formed XML. So, I expect that when the dust settles, the responsibility of a transport binding will be (roughly) to move the envelope Infoset to the next point in the message path, and to reconstruct it there. The binding corresponding to the current SOAP v 1.1 HTTP binding will indeed use the standard serialization in well formed XML: it will have the angle brackets that everyone expects. Indeed, its messages may be nearly indistinguishable from those used today for SOAP v1.1. Lots of other bindings will make the same choice, but others such as those that do compression will have wire formats that use other forms for the Infoset. I think that those of us who are enthusiastic about the Infoset formulation roughly agree on the above. I am only pointing out that, without the discussion of bindings, readers may be confused. In summary, I really like where this is going, but I don't think it quite stands alone yet. Gudge: thanks so much for moving this ahead. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Friday, 29 June 2001 20:18:57 UTC