!-Re: ebXML Abandons SOAP

Adam,

This has been a fun discussion. I certainly agree with you about your point
about simplicity vs. purity, but I also suspect that we're dealing with
different philosophies about what constitutes simplicity. From the
standpoint of the web application, clearly, the MIME-enclosing envelope
works best for transporting information of any sort -- the infrastructure
already exists. Just for clarification, I'm going to refer to a MIME
enclosing solution as "enveloped", while a scheme where XML contains the
MIME content would be "exveloped" (think endoskeleton and exoskeleton). The
problem comes when an enveloped application is used within a stand-alone XML
system -- you don't want to have to parse the XML out of the MIME enclosed
content.

On the other hand, if you go the other route, then you're forced into trying
to move XML over HTTP, you run into the danger of a single proprietary
solution dominating (aka SOAP or JAVX), and things get otherwise messy.

One possible solution might be to make use of processing instructions. You
could essentially keep the whole structure within a formal XML document,
since PIs don't have to be within the internal content, yet you still have
something that can easily be parsed by an XML processor:

<?xml version="1.0"?>
<?http-content-type text/xml?>
<document>
    <!-- this is XML Content -->
</document>
<?http-content-type image/jpg?>
<?http-content ac12dffeaffc562a... ?>
<?http-end?>

Writing an HTTP processor to parse this kind of envelope would be relatively
simple, yet it would still parse properly with an XML parser. Moreover, this
information would still be available to the XML parser as well -- I could
for example search through DOM xfor all instances of <?http-content-type
image/jpeg?>, read the content contained in the following <?http-content?>
as either text or binary content, depending upon encoding, and work with the
resulting data.

Not having seen MIME-XML I don't really know what form it would end up
taking, but this form would seem to make as much sense as any.

-- Kurt Cagle

----- Original Message -----
From: "Jack, Adam" <AJack@neonsoft.com>
To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>; "Kurt Cagle"
<cagle@olywa.net>; <xml-dist-app@w3.org>
Sent: Monday, October 02, 2000 5:02 PM
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 Monday, 2 October 2000 20:38:24 UTC