How do *you* use XML within the world of web applications?

Question

Background
I'm researching the efficiency of messaging within contemporary web applications, examining the use of alternatives to XML. This is a university project whose results will be released publicly - the greater the participation of the community, the greater the value of the results that are given back.

I need as many real-life examples of XML in use as possible so as to:

• fully understand to what uses XML is put when host A talks to host B
  I can certainly imagine how XML should/may be used. The reality may be quite different.
   
• perform tests on actual not hypothetical data
  How XML performs compared to Technology X on sets of real-life data is of equal importance to how XML compares to Technology X on an arbitrary set of data
   
• identify and measure any patterns of use of XML
   e.g. elements-only, elements plus some attributes or minimal elements and heavy attribute usage

The Question

How do you use XML within the world of web applications?

When Host B returns XML-structured data to Host A over HTTP, what comes back? This may be a server returning data in an AJAX environment or one server collating data from one or more other servers.

Ideal answers would include:

• A real-life example of XML within an HTTP response
• The URL, where relevant, to request the above
• An explanation, if needed, of what the data represents
• An explanation, if not obvious, of why such messages are being exchanged (e.g. to fulfil a user request; host X returning a health status report to host Y)

I'd prefer examples from applications/services that you've made, developed or worked on, although any examples are welcome. Anything from a 5-line XML document to a 10,000 line monster would be great.

Your own opinions on the use of XML in your example would also be wonderful (e.g. we implemented XML-structured responses because of Requirement X/Person Y even though I thought JSON would have been better because ...; or, we use XML to do this because [really good reason] and it's just the best choice for the job).

Update
I very much appreciate all answers on the topic of XML in general, however what I'm really looking for is real-life examples of HTTP response bodies containing XML.

I'm currently fairly aware of the history of XML, of what common alternatives may exist and how they may compare in features and suitability to given scenarios.

What would be of greater benefit would be a impression of how XML is currently used in the exchange of data between HTTP hosts regardless of whether any current usage is correct or suitable. Examples of cases where XML is misapplied are just as valuable as cases where XML is correctly-applied.

Answer 1

I try not to use it more than I have to. It definitely has its place as a transmission protocol in an architecture where the client and the server do not know about each other and are implemented independently - or an API is being developed independently of any clients. It also has a place in persistence where the same reasoning applies, and I object to it far less in that domain.

However, if the client and server are implemented by the same team then it makes little sense to translate back and forth between the two in a human readable form and there is almost always a faster, cheaper (in terms of processing) alternative, even if the client and server technologies are different.

Concentrating my remarks on transmission protocols, back before XML arrived in the "bad" old client/server days when bandwidth and processing power were precious, it would be the job of the architects to design a protocol (normally binary) with the sole job of efficiency and speed where packet size would be minimized. The obvious limitation is that the handshake was very specific and the binary dialect was unintelligible unless it was published. The up-side was that it was extremely efficient and could be highly optimised for the application at hand. Very often the binary formats were published (have you seen the old Excel BIFF specification - not a protocol, but an example of publishing a binary format).

XML in HTTP, i.e. SOAP, broke that. The rationale was very sane, have a universally understood protocol for the handshake, a sort of computer Esperanto, so that you could separate your client and server architectures and decide on their pace of development and internals completely separately. What's more, future-proof yourself against possible client requirements with the promise that switching clients was just a matter of implementing a new one. What's more, allow any Joe with an XML parser to consume your API. All great stuff and has led to a mushrooming of very well demarked architectures - which is wholly good.

So to quite a large degree the power of this proposition has been manifested and there are clearly advantages, however I think that a) this requirement is often overstated and b) XML protocols are often implemented very sloppily and with scant regard for the processing cost they imply. What's more the originally sane reasoning has given way to cases of extremist religion (I bet I get voted down) and I have seen code passing XML between function calls within the same classes, using exactly the future-proofing rationale and functional separation arguments, which is clearly bonkers.

So my mantra is to make the communication efficient and effective. If that means providing a generalised API and protocol for arbitrary and unknown consumers, then XML is a very good choice. If it means making lightning hot, scalable client/server (i.e. Web) architectures then I try and use a binary protocol, often rolling my own.

The emergence of JSON is testimony to the fact that the XML bandwagon had a few too many layers. JSON is an attempt to shorten the structural elements while maintaining the generality and thereby get the benefits of smaller packets. Protocols like Adobe's AMF are generally much more compact, being almost entirely binary.

And that's where I think the future probably lies. I am certain that it will be possible to keep all of the up-sides that XML represents for publication of interfaces, but be able to trim it dramatically and make it less processor and bandwidth intensive - at least that's my mission as developer and architect.

Imagine if your average client/server request was 1/10th of the size and there was no text parsing at either end, but you retained the generality of the interface. I don't know any developer who wouldn't take that.

Answer 2

Probably not the answer you want, but I never use XML, it's too complicated, (for my simple needs anyway), but even if my needs were complicated, XML is too complicated a beast it scares me to use it in a complicated problem.