- From: Michael Brennan <Michael_Brennan@Allegis.com>
- Date: Mon, 2 Oct 2000 18:08:33 -0700
- To: xml-dist-app@w3.org
> 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