- From: Jack, Adam <AJack@neonsoft.com>
- Date: Mon, 2 Oct 2000 18:02:39 -0600
- To: Henrik Frystyk Nielsen <frystyk@microsoft.com>, Kurt Cagle <cagle@olywa.net>, xml-dist-app@w3.org
Henrik et al, I don't see why being able to transfer binary and/or xml data within a message has much do with what the message is being used for. In other words, whether the message is being used for messaging or RPC or whatever seems to me to be orthogonal to the question of how to embed binary and xml data within a message. Sure they are theoretically orthogonal, and maybe that is sufficient to close this argument. That said however, one attribute of a successful/interoperable standard has been simplicity not theoretical purity. (I was involved w/ X.400 many moons ago and SMTP, for all its warts, has done the world more favours.) I think that "a simple way to pass any type of message" is a worthy goal for a messaging mechanism (and it need not be for an RPC mechanism.) Passing references to data or encoding the data is a workable theoretical solution but I wonder if it is practical, and simple enough to be interoperable. Say that XP runs on an IP port, then will firewall admins open one port -- or many? Will it mean HTTP can come into an enterprise to access data, plus FTP, plus .... etc etc. Sending packets of XML in/out of an enterprise is scary (and exciting) enough, I just don't believe that dependence upon another protocol is practical, or going to be widely adopted/accepted. [Note: I don't claim to be an expert to know for sure, I am just stating my opinion (as somebody who wants to use XP to do these things.)] The purpose of the SOAP message is to provide a consistent and well-defined processing model for the whole message and to allow for a rich composability model where features can live side by side in the same message without stepping on each other. This is the reason for the definition of the term "SOAP processor". Doing this for XML in anything but XML would be extremely difficult unless the data model is the same as for XML in which case we might as well use XML in the first place. Am I missing something to ask if this is not orthogonal to where the data sits in the message? ;-) Is this not still valid if XP looked more something like: <?xml .. ?> <XP-SOAP Extensible XML Header> ... </XP-SOAP Extensible XML Header> XP-Header-Length=XXXX XP-Content-Type=YYYY XP-Start-Data-Here- - - - - - - - - [Lump-O-Binary/XML/Any Data...] ... and this (to me) looks less like a function call, and more like a message. To me this is simple: XML (today) just isn't a good XML envelope, but it is good for extensibility of headers, and as a message body part. Why make us mess around with encodings when a simple enveloping mechanism would remove the need, keep it simple, and still have it extensible. regards, Adam
Received on Monday, 2 October 2000 20:07:40 UTC