XML FROM 30,000 FEET
When developing XML solutions, it is very easy to get bogged down in 
the details of tag names and attributes. Losing sight of the problem at 
hand can undermine the success of the project. Rather than diving right 
into the specifics, it can be useful to look at XML solutions from a 
higher level and understand how it fits into the bigger picture.

THE BLOB
One of the interesting things about XML is how nontechnical people view 
it as nebulous and abstract. They often picture XML as the monster in 
the movie The Blob; they aren't quite sure what it is. It may not be 
important for the nontechnical participants in a project to have a full 
technical understanding of XML, but providing concrete illustrations 
can help them better envision how this technology can help your 
organization.

LIVING BY EXAMPLE
One of the best ways to explain XML without getting into details is to 
use an example. By illustrating how data looks in an older technology 
or format and how it looks in XML can go a long way towards making a 
point. Before XML, data could be stored and shared in a variety of 
formats. Some of the most common formats were (and still are) ASCII 
files. For example, the following data is in a fixed-length ASCII 
format:

JONES          JOHN     55555512129902 BROADWAY      NEW YORK        
NY10010 
SMITH          MABEL    5555559999674  ANYSTREET     CHICAGO         
IL60614

With XML, this data would look a lot different. To start with, the 
"fields" wouldn't be set to a particular length, and there wouldn't be 
a lot of white-space data. Also, it would be easy to tell where the 
phone number ends and the street address begins just by looking at the 
data. Here's an example of the above data in XML:

<Customers> 
          <Customer> 
                    <LastName>JONES</LastName> 
                    <FirstName>JOHN</FirstName> 
                    <Telephone>5555551212</Telephone> 
                    <Address>9902 BROADWAY</Address> 
                    <City>NEW YORK</City> 
                    <State>NY</State> 
                    <Zip>10010</Zip> 
          </Customer> 
          <Customer> 
                    <LastName>SMITH</LastName> 
                    <FirstName>MABEL</FirstName> 
                    <Telephone>5555559999</Telephone> 
                    <Address>674 ANYSTREET</Address> 
                    <City>CHICAGO</City> 
                    <State>IL</State> 
                    <Zip>60614</Zip> 
           </Customer> 
</Customers>

ADDING MEANING
Beyond the obvious structural differences to the data, there are 
several advantages to using XML over a fixed-length (or other) ASCII 
format. With data such as customer names and addresses, it's easy to 
visually identify the ASCII data. However, if the data weren't such 
common items, it would be more difficult to look at the file and make 
estimations about whether the data is correct or if it's the correct 
format.

With an XML document, there's meaning attached to each piece of data. 
Each field is wrapped by a tag that identifies what the data is or 
isn't. When everything in an application is running fine, this may not 
be such a big deal. When there are errors, it can be a major issue. By 
simply looking at the data in an XML file, it can be very easy to 
identify if the file is using the correct XML grammar and if there are 
any problems with the data.

STANDARD AND EXTENSIBLE
Two of the most important aspects of XML solutions are that they are 
both standardized and extensible. "Standardized" means a set of rules 
governs the data being specified by the particular XML grammar. Once 
both parties agree to a particular grammar, they have reached a 
particular standard that data being sent and received can be checked 
against. Data that meets the standard can be considered good, and data 
that doesn't can be moved into the error bucket.

One of the great things about XML is its extensibility. Once a 
particular standard has been established, it can be extended to 
accommodate new features or new pieces of data. For example, if a 
customer record needs to include a ZIP code and a plus-4 ZIP code 
extension, it can simply extend the existing customer XML grammar 
without impacting the rest of the fields.

Brian Schaffner is a senior consultant for DMR Consulting, a Fujitsu 
company. He provides architecture, design, and development support for 
DMR's Telcom360 group.

-------------------------------------------