W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2000

RE: ebXML Abandons SOAP

From: Jack, Adam <AJack@neonsoft.com>
Date: Mon, 2 Oct 2000 18:02:39 -0600
Message-ID: <A7722E58BBE8D311B46C0090273AD8D4EF2169@DNEXCHANGE2>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:57 GMT