Chapter 7: Handling XML

That minds me of our Viscount loon—Sir Kenneth’s kin—the chap
Wi’ russia leather tennis-shoon an’ spar-decked yachtin’-cap.
I showed him round last week, o’er all—an’ at the last says he:
“Mister McAndrews, don’t you think steam spoils romance at sea?”
Damned ijjit! I’d been doon that morn to see what ailed the throws,
Manholin’, on my back—the cranks three inches off my nose.

—Rudyard Kipling, writing on the impossibility of explaining
technical wizardry to managers, “McAndrew’s Hymn,” 1894.

Problem Background

XML is now the universally accepted wire format for transmitting data among distributed systems. For example, we saw in Chapter 4 how XML Web services carry the data in cross-machine function calls, and in Chapter 6 how a data set serializes itself into XML for easy transmission from server to client and back. The modern computing world has many other uses for XML, with more arriving daily, so help with handling XML documents and streams is one of the most important functions that an operating system can provide to an application programmer.

XML pervades the modern computing environment, so we need operating system help with it.

The most common use of XML we encounter is the XML-based industry standard vocabulary for communicating among separate parties in a particular industry or within a company. For example, the insurance industry uses a vocabulary called ACORD XML (www.acord.org), and the health care industry uses a vocabulary called Health Level 7, or HL7 (www.hl7.org). The process of using an XML vocabulary to communicate is shown in Figure 7-1. For example, let’s say a client (a doctor’s office, an insurance agent) sends an XML document containing a command (admit a patient) or a request (quote this proposed policy) and all the data required to support that operation (the patient’s name, history, and diagnosis; the location and description of the insured premises and the type of coverage desired) to a recipient (a hospital, an insurance company’s head office). The recipient reads the information from the XML document, performs its business logic, and generates a response document to return to the sender (patient admitted to this bed of that unit, your insurance will cost so much—and look at these cool add-ons you can foist on the poor schmoe to raise your commission). While situations of this type may seem tailor-made for XML Web services, distributed systems often don’t want to use HTTP as their underlying transport mechanism, preferring asynchronous store-and-forward channels such as MSMQ or even e- mail. We need an easy way to read the contents of incoming XML documents and to generate outgoing documents.

Even though we have XML Web services, we still need to read and write XML documents.

Figure 7-1: XML document used as command or request and response between different systems.

Most operating systems come with an XML parser, a utility object that performs the lowest-level tasks of handling XML documents. The parser reads an XML document, checks to see that it is properly constructed, and then exposes some sort of generic interface to allow client programs to read and write it. Application programmers don’t have to worry about the lowest-level tasks such as counting angle brackets or matching tag names, which makes life easier than it would be without a parser. But the parsers are by their very nature generic, so they don’t fit any particular task very well. Application programmers constantly need to deal with the medium-level implementation details of an XML document—for example, is this particular piece of data represented by an XML element or an attribute? Programmers spend most of their time writing code similar to that shown in Listing 7-1, identifying individual pieces of data with long, complex strings, which are damnably hard to get right. It looks easy, but try it for an hour and you’ll see that it isn’t. You have to type in the exact string that you want every time, and your program dies if you get just one letter incorrectly capitalized. There’s no notion of data typing; the parser returns all values as strings and you have to convert them by hand to whatever you think they ought to be. IntelliSense doesn’t work in parsers, so you have to keep flipping back and forth to the documentation. We need another way of accessing XML documents other than from within a generic parser that makes them easier to write and harder to get wrong. We’d really like our XML documents to magically become .NET classes so that we can bring the power of the .NET Framework to bear on them.

Generic XML parsers are hard to write code for, so we’d like a way to transform XML documents into .NET classes.

Listing 7-1: Code used to access an XML element in a generic parser.

Password = DocOut.selectSingleNode _ ("/TXLife/UserAuthRequest/UserPswd/Pswd").Text

While the problem we most frequently encounter is having to repetitively deal with the same type of document, we still sometimes need the capabilities of a generic parser. Designers of, say, an XML editor utility have to deal with arbitrary XML documents whose structure they don’t know about at design time. The existing Microsoft XML parser uses COM as its interface to client applications. Our .NET applications could use that parser via the COM compatibility layer described in Chapter 2. However, our programs would then require the powerful and double-edged code security permission of accessing unmanaged code, which administrators do not like to grant. So in addition to easy access to repetitive documents, we also need generic parsing capability in our managed .NET world.

We still need generic parsing capability in .NET.