Protocols for XML delivery

bullet1 Functional requirements

Partially taken from a summary attributed to Dave Crocker in Marshall Rose's book BEEP, The Definitive Guide.

  • Push or pull
  • Synchronous/asynchronous delivery
  • Stateful (session)/stateless
  • Multi-channel
  • Timeliness
  • Reliability
  • XML-only/arbitrary content
  • Readability

bullet2 Push or pull

bullet2 Synchronous/asynchronous delivery

bullet2 Stateful (session)/stateless

bullet2 Multi-channel

bullet2 Timeliness

bullet2 Reliability

bullet2 XML-only/arbitrary content

bullet2 Readability

On the balance between readability and programmatic interface.

In general, the most readable forms of XML are hand-crafted.  There is a real tension, and readability is soon eroded, when other considerations come in to play. For example, I view one of the most powerful features of XML, extensibility wise, is namespaces [1].  But using namespaces in XML does tend to clutter otherwise simple XML data.  I think that's something we need to live with.  At least namespaces can be "tucked into a corner" for simple cases.

The readability of hand-crafted, roll-your-own, single-application XML seems difficult to maintain when moving towards generic communication frameworks (SOAP, WSDL, and the rest) it does seem difficult to maintain the simple ease-of-reading.  Although I think that you can learn to read many of these in time.  Beyond the simplest applications, I tend to think of XML as NOT being a human-readable  format.