Xml Protocol

XML Protocol is a W3C Working group.

See it at http://www.w3.org/ or, more specifically http://www.w3.org/2000/xp/

XML Protocol Activity: "The goal of XML Protocol is to develop technologies which allow two or more peers to communicate in a distributed environment, using the ExtensibleMarkupLanguage as its encapsulation language. Solutions developed by this activity allow a layered architecture on top of an extensible and simple messaging format, which provides robustness, simplicity, reusability and interoperability."

Quick impression is that this is the W3C committee to evaluate the SimpleObjectAccessProtocol.

Perhaps others too, see...

XML Protocol Comparisons:: http://www.w3.org/2000/03/29-XML-protocol-matrix

Since efforts like Jabber <http://www.jabber.org/> and SimpleObjectAccessProtocol hit the scene and made lots of hypish noise, I've been pondering what we actually gain from basing an interprocess communication protocol on a document markup format. (I also have a slight beef with using a document markup language to represent database rows when other formats could do that much more efficiently as well, but I suppose being able to format them with stylesheet languages on the fly is justification enough.)

I'm quite serious here; I really don't see what we gain by using XML for IPC. Perhaps someone could enlighten me. -- MattBehrens

A: It's plain text format, and you can get it through port 80. It's hoped that this will make it more palatable (less scary) to the security people, making it politically possible to get it through the firewall.

Having worn the security person hat as well as railed against other security people, I can tell you right now that if you start passing arbitrary object calls in and out of the firewall, the security people are going to have a fit the first time one of those calls results in a security compromise somewhere, and that compromise is publicized.

This is a peripheral issue to XML's fitness as a protocol - firewalls that filter on port number will allow not just XML, but my-cool-protocol or anything else to be passed through a port that they have open. It doesn't take XML to tunnel through a firewall.

XML brings graceful degradation as well. It also allows you to have only one parser instead of twenty. This makes new protocol development fast, because you only have to deal with the real logic, not the regexes. This is especially important with a project like Jabber that seeks to levy multiple higher level protocols on a simple low level protocol. If the end clients aren't aware of a particular protocol, they don't have to deal with it. But how are they supposed to tell what they can understand if the input formats are totally random? XML provides enough structured flexibility to ratchet the industry up a notch from proprietary and conflicting schema definitions.

Furthermore, XML is embeddable. You can embed an entire XML document as a child in another. This allows protocol developers to quickly implement functionality by simply subsuming an existing protocol (and its implementation).

Network efficiency isn't as important as network functionality. OptimizeLater, dammit. -- SunirShah

Hold on a minute. This isn't OptimizeLater, it's "optimize never". You can't optimize a protocol that's set in stone unless you deviate from it, and then you're not using that protocol anymore. This is about choosing a technology that's right for your needs, and I submit that XML is not the right technology for all needs.

XML also doesn't magically confer departure from proprietary behavior. The industry is perfectly capable of making proprietary protocol out of XML (think Office 2000's save as "XML" feature). It's just a tad easier to reverse engineer.

Beyond those gripes, I thank you for the enlightenment. -- MattBehrens

How does it bring "graceful degradation"? I don't get it. -- GlennVanderburg

You ignore what you don't understand, and you fill in with defaults what is missing. This is the most elegant way to deal with version conflicts. Think of the absolute opposite of anything Java does, and you get the philosophy behind XML. HaHaOnlySerious. -- SunirShah

Thanks for the answer, Sunir. I wouldn't use the word "degradation" for what you describe, however. -- GlennVanderburg

You don't have to change the protocol to optimize it. To the best of my knowledge, there are several schemes to compress XML, especially over the wire. -- sg

Doesn't that then bring you incompatibility, unless you can compress an both sides of the wire? If you're going to use an XML IPC protocol to chat between objects in different technology stacks, you'll need that same scheme available on both stacks. HTTP, unless managed very carefully, also has the overhead of lots of session setup and teardown. (I must say I'm probably extrapolating a bit here, but I think the answers to these questions are valuable for these pages anyway...)

Wireless devices use MNP4 on both sides of the connection.

Another thing about XML is that it's self describing - it carries semantics around with it. To use OliverSims' term, it's a semantic data stream. Traditional RPC-based protocols require a tight coupling of the actual "positioning" of the data. This tends to tie the wire protocol to a particular object or language model. XML doesn't have that. It also often will require a compile-time linkage (or early binding), which again, limits the openness of the protocol. Attempts to use runtime linkage on top of older RPC-based protocols were usually hacks: COM automation, CORBA's DII, using Java reflection on top of an RMI interface, etc. In XML, it provides a natural runtime type checking mechanism (a DTD or Schema), and provides several flexibly ways of linking to the protocol (a SOAP runtime, SAX parser, DOM parser, etc.) -- StuCharlton