RE: ebXML Abandons SOAP

Hmmm... I think I would tend to ask: what really is the difference between:

	<?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 something like:

	<?xml .. ?>
      <Envelope>
		<Header>
			<ContentType>YYYY</ContentType>
		</Header>
		<Body>
			<!-- Lump-O-Binary/XML/Any Data -->
		</Body>
      </Envelope>

There really is no difference as long as we can come to an agreement on
exactly how to insert the lump-o-binary into the body.  That issue could be
addressed through adjustments to the XML specification rather easily.  Such
a solution would still be compatible with existing application architectures
(it would still be compatible with MIME, HTTP, etc) and would solve several
problems in a single go (not just XML-protocol related issues).

Personally, I think that building an XML-based protocol that forms the basis
of a new SMTP/HTTP/etc would not have a strong impact on network security
administration.  If you think about it, there really wouldn't be much of a
difference than what we have today.  XHTTP would be accepted on Port X, XFTP
would be accepted on Port Y, XSMTP on port Z, and so on.  The beneficial
part about such an architecture, however, would be that the server would
only need to implement a single processor for each, with protocol specific
plugins performing the actual work -- so, instead of multiple applications
monitoring multiple ports, with separate security configurations for each,
you could have a single application monitoring multiple ports, across
multiple protocols with a standard security configuration for all.  Just a
thought though, I don't claim to be an expert on security related issues
either.

As for the simplicity versus purity argument... I would agree that the final
solution must weigh in more on the side of simplicity than purity, however,
as I've already mentioned, I do not think there are enough differences in
the two ideas (MIME-style enveloping versus XML-based enveloping) to cause
much problems in the way of simplicity.  Once we've settled on a standard
method of embedding binary into XML, in my opinion it would be just as easy
to take either path.

- James Snell


-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Jack, Adam
Sent: Monday, October 02, 2000 5:03 PM
To: Henrik Frystyk Nielsen; Kurt Cagle; xml-dist-app@w3.org
Subject: RE: ebXML Abandons SOAP


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 Tuesday, 3 October 2000 01:22:22 UTC