Message Processing with XML

To justify serializing object-oriented messages in XML, there ultimately must be recognized cost benefits to doing so. The software engineering discipline has come to recognize that actual development of code represents but a small fraction of the actual life-cycle costs. Code maintenance will inevitably accounts for the vast majority of outlays; thus, wherever possible, organizations should seek to acquire standards-based software for integration rather than writing proprietary, in-house solutions.

For example, consider a data structure for a message representing N number of digital assets, each of which contains metadata and content. This could be expressed using an ASCII-based, proprietary format as such:

[ASSET/METADATA]
NAME=Daytona 500
DATE=February, 2000

[ASSET/CONTENT]
FILE=daytona.jpg

Advantages

This approach has a number of distinct disadvantages. The processing of data formats ultimately requires two (2) types of validation:

• Structural

• Datatype

Structural validation rules specify thing covers ordering of data members, cardinality. Content validation requires fields to be validated to warrant conformance to prescribed parameters:

• Is it a date field? If so, is the date specified valid (no February 31^st allowed)? Is it Y2K compliant?

• Is the field numeric? If so, does it conform within prescribed limits?

• Is the field variable character data? If so, does it have an upper bound on its length?

• Is the field an enumerated type? If so, what are the valid values?

Even more fundamental are the following issues. Where does one field end and the next begin? Where does one section [field grouping] end and the next begin. How is containment defined? What white-space is significant, and how should the end of each line be treated? What represents a recoverable error when parsing the data? In the ASCII based scenario above, the responsibility for the specification of behavior is on the file format designer. Employing a standards-based approach such as XML, the standard itself answers these questions. With fundamental design decisions having been answered, the software developer can focus attention to implementing a solution.

Many XML parsers are available. Current APIs for processing XML, either serially or in random access mode, are, respectively, SAX (Simple API for XML) and DOM (Document Object Model). SAX is an event driven interface wherein the programmer specifies control logic for events that may occur, and as the XML parser encounters event conditions, SAX passed control to the event handler, which invoke the code prescribed for a specific event.

Specifications for ensuring structural validity for XML data are DTDs, utility descending from SGML heritage and a sundry of schema proposals that employ the actual XML syntax to describe structural validation criteria. DTD enabled validation is available by all validating XML parsers. Schema based validation can be employed via source libraries supporting the specifics of particular schema specification.

Some schemas, such as the working draft of XML Schema, made available by the W3C, provide both structural and datatype validation. Ultimately, all of the strategies provide a well-defined procedure to define validation rules, which can be enumerated within or separate from the actual runtime code. Because these are self describing, the can intuitively be modified by software developers or integrators. Because these are well-defined approaches, tools availability is generally forthcoming, which translates into lines of code not written, not maintained, and subsequently, cost savings within the software development lifecycle.