Presents your 
XML E-NEWSLETTER for October 30, 2002

<------------------------------------------->

CREATE PRECISION STANDARDS FOR XML ELEMENTS

How many times have you received an XML document from an external 
source
and the data was all there, but you knew you would need to tweak it to
make it work with your system? It's a common problem that is often the
result of a lack of precision. Being more precise can alleviate 
problems
with many common data types. Let's look at some examples of how you can
create precision standards for your XML elements.

THE NAME GAME

One of the most common problematic elements is one that includes name
information. Here are a few of the many name formats:


* SCHAFFNER, BRIAN

* Brian T. Schaffner

* Mr. Brian Schaffner

* Rev. Dr. Brian Schaffner, III


There are several different formats for someone's name, and 
communicating it 
in XML can be confusing if there's not enough precision in your 
elements to 
hold each component. Let's try to create an all-encompassing name 
element that 
you can use for nearly any name.

We'll start with the first part of the name--the prefix. Of course, 
there may 
be more than one prefix (as in the Reverend Doctor), so you'll need 
space for 
multiple prefixes, and probably something that indicates their proper 
order. 
Next is the first or proper name followed by one or more middle names 
(or 
perhaps an initial, or perhaps no middle name). Nearly last is the last 
name or surname followed by the suffix (as in Jr.). When put together, 
it might end up like this:

<Name>
  <Prefix order="1">
    <Abbreviated>Rev.</Abbreviated>
    <LongForm>Reverend</LongForm>
  </Prefix>
  <Prefix order="2">
    <Abbreviated>Dr.</Abbreviated>
    <LongForm>Doctor</LongForm>
  </Prefix>
  <Proper>Brian</Proper>
  <Middle>T.</Middle>
  <Surname>Schaffner</Surname>
  <Suffix order="1">
    <Abbreviated>III</Abbreviated>
    <LongForm>the third</LongForm>
  </Suffix>
</Name>

XML PHONE HOME

Another element in XML documents that frequently suffers from format
abuse is telephone numbers. Here are a few of the many ways to format
telephone numbers:


* (502) 555-1212

* 502.555.1212

* 5025551212

* 502-555-1212

* +1(502)-555-1212 x334


There certainly are others that aren't listed here. You can run into 
the
same problem with phone numbers as you do with names. The solution is 
to
determine what are all the possible components that a telephone number
may include and create a model that supports them. That way you won't 
lose
any information in your XML documents.

We've identified five important components of a telephone number above.
They start with the country code and end with the extension number.
Creating a comprehensive telephone number element shouldn't be too 
difficult
with this information:

<TelephoneNumber>
  <CountryCode>1</CountryCode>
  <AreaCode>502</AreaCode>
  <Exchange>555</Exchange>
  <Number>1212</Number>
  <Extension>334</Extension>
</TelephoneNumber>

MAY BE LONG WINDED

The above examples may seem a bit verbose for something as mundane as a
name or phone number. For enterprise systems where data is in a variety
of formats and integrates with many other systems, a comprehensive
standard can go a long way towards eliminating problems. The idea is 
to create a format that supports all possible data of a particular 
type. 
For example, if you had an XML solution for a person's name that failed 
to include the suffix or allowed only a single prefix, you could lose 
important information about someone whose name included those 
attributes.

STANDARDS GOOD, CHAOS BAD

The point of all this fuss is that it's a good idea to create a standard
format for common data types. Having a standard forces data to be consistent
--which can make your applications more relliable. If you are certain 
that data is in a particular format, then your application can concentrate on 
processing the data rather than on trying to decipher it. When the data is 
chaotic, your application may spend more time determining what kind of data it's 
looking at and less time doing something useful with it.

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

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