RE: !-Re: ebXML Abandons SOAP

> From: Kurt Cagle [mailto:cagle@olywa.net]
> [...]
> 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.

Ultimately, when sending XML over HTTP (or SMTP) you are always sending it
in a MIME envelope. It's just not a multipart MIME envelope. When this is
done correctly (e.g. properly specifying the "Content-Type" header and
including the proper character encoding in the "charset" parameter for that
header), this works beautifully, can be done quite easily with existing
(cheap and/or free) tools, and works over existing infrastructure. I'm not
sure why this is dangerous, nor do I understand why SOAP is "proprietary".
Seeing a single solution dominate -- so long as it is open, extensible, and
modular -- would be a good thing. It would help promote interoperability.
That's kind of what the whole W3C XML Protocol Activity is all about. Maybe
I'm not understanding your point correctly.
 
> 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:

PIs are one of those unfortunate legacy's from XML's SGML roots that, IMHO,
should be avoided like the plague. They are kind of like a "loophole" in
XML. I don't think it would be a good idea to use them as a foundation for
an enveloping scheme. There is no way to validate a PI against a schema or
DTD, for instance. The XML standard doesn't even try to address any standard
syntax for PIs. (Which, I think, is kind of the point. They are like a
"loophole" in XML for getting proprietary application-specific directives
into XML that are not part of the content.)

Received on Monday, 2 October 2000 21:17:06 UTC