What is XML?

Extensible markup language is “a markup language for documents containing structured information.” (www.xml.com) XML has many uses, but it is most commonly used for structuring data within a text document that travels easily over the internet via HTTP. Virtually any computer can request data from an XML web service and read in the data contained in that document. The data may then be pulled into an application, displayed on the screen or stored for future use on a network hard drive.

They call XML extensible because it is not limited, the way HTML is, to a small set of standard tags like <TABLE>. XML tags can be devised to fit the data they represent. For example, address data can be sectioned into logical components (address number, street, and so on). Moreover, XML supports hierarchical data—data in which a single attribute may have one or more “child” attributes. For example, a property may (or may not) have one or more building permits, code violations or ownership transactions. These can be embedded in the XML, with the child data clearly shown at a more detailed logical level than the property itself.

Below is an example of XML text that might be returned from a hypothetical web service called GetBuildingPermits. (Note to FGDC sticklers and all other sticklers: this is a simplified example to convey a sense of what XML looks like.)

<?xml version="1.0" encoding="ISO-8859-1"?>

<streetname>Fullerton</streetname>

<postalplacename>Chicago</postalplacename>

</address>

<permittype>Repairs General</permittype>

<worktype>ALTERATION - SAME USE</worktype>

<buildingtype>Single Family Dwelling</buildingtype>

<bldgconstruction>Brick Construction</bldgconstruction>

</buildingpermit>

<permittype>New Construction</permittype>

<worktype>NEW CONSTRUCTION</worktype>

<buildingtype>Non-Residential</buildingtype>

<bldgconstruction>Frame Construction</bldgconstruction>

<gencontractor>OWNER</gencontractor>

</buildingpermit>

</buildingpermits>

</property>

</properties>

Note that this same data could have been arranged with <buildingpermits> as the root node, and <address> as a child element of each building permit record. I chose this layout because to me it makes more sense to see <address> as an element of a property, not a permit. XML’s greatest strength—its flexibility—is also the reason why it demands a great deal of agreement among users of a particular XML service.

Service-Oriented Architecture (SOA)

Web services are not just for data exchange with external partners; they also work well for cross-departmental sharing. A city government wishing to provide a one-page parcel profile for use by city employees might create a web form that pulls together property ownership, permits, physical characteristics, business licenses, court records, crime data, any public financing or subsidies, historic value of the structure, building condition and many other attributes. If a central IT department has control over all this data, great! You may not need web services. But typically these bits of information are housed and owned by various data stewards across several departments. A series of lightweight web services could be deployed as interfaces between departments.

But while web services work very well as add-ons to legacy systems, they are much more powerful when integrated into the core of an enterprise architecture. SOA, or service-oriented architecture, enjoys a great deal of support from IT professionals because of its loose coupling, code reuse, flexibility and emphasis on business process documentation. In these respects SOA is a specific form of Enterprise Architecture (EA), which is now strongly endorsed by many IT standards bodies—most notably within the federal government. The Federal Enterprise Architecture initiative led by the Office of Management and Budget (OMB) is changing the way federal agencies operate. OMB defines EA as “The explicit description and documentation of the current and desired relationships among business and management processes and information technology.”