It was five years ago that I was seated at a table, in some dimly lit hotel meeting room, discussing with fellow American Land Title Association® Systems Committee members which steps were needed to enable the title industry to facilitate paperless transactions. The objective, of course, was to design and develop uniform transaction sets (standards) for the title industry for the purpose of ushering in electronic data interchange (EDI) into our daily operations and business systems. There we were, surrounded by stacks of paper documentation on business data elements, data dictionaries, business scenarios, sample data streams, and, of course, the two 3-inch thick volumes of X12 standards created by the Accredited Standards Committee (or X12 Committee) of the American National Standards Institute (ANSI). (If I’ve lost you so far with "techno jargon," please forward this article to your technical person!)
The ultimate result of all this was three industry X12 transaction sets: the 265 (Title Order Request/Response), the 197 (Title Evidence), the 199 (HUD Settlement Information) and their corresponding ALTA® Implementation Guides. We all reveled in our satisfaction of seeing the culmination of our hard work result in approval and publication by the Data Interchange Standards Association (DISA) and ALTA®. Now, we would sit back and watch our industry transform its manual, paper-intensive processes into faster, more efficient automated ones. Unfortunately, many people, outside of those involved with the X12 development efforts, found the X12 syntax confusing and difficult to understand. Additionally, the front-end costs of purchasing translation software, and hiring/training EDI-savvy personnel were considered to be way too expensive and prohibitive for small and even medium-sized operations to consider. Secretly, behind the scenes, a new technology was emerging.
Markup Languages"Separating Content from Presentation
In the early 1970s, Dr. C.F. Goldfarb of IBM had developed a method for describing text (hint""data") that was not specific to any one application. It focused on describing the structure of a document (not the formatting and styles) and its syntax was clear and easy to read by humans. This language was the precursor to what became known as SGML (Standard Generalized Markup Language) in 1986. With the explosion of the World Wide Web and Internet browsers, HTML (Hypertext Markup Language) was introduced in 1991.
The primary purpose of HTML was that of formatting and presenting information, not providing for a structured framework of documents and data. What was needed was a markup language which could accommodate both presentation (for browsers) and content information (for applications). Thus XML, or eXtensible Markup Language was born. XML is a metadata markup language, meaning that it contains data about the data in it. Additionally, XML allows for the creation of new tags (or elements), thus giving it extensibility for a wide range of applications.
We now have the capability to define tags for application business data elements, such as <Borrower-FirstName> and be able to easily process the file, find the <Borrower-FirstName> element, and retrieve its associated data (the actual borrower’s first name). Unfortunately, the very feature that provides such powerful capabilities can also be the one to inflict the most damage.
What About Rules?
Ah, rules. Life just wouldn’t be manageable without some sort of rules. If we are to consider XML as the data interchange format for future B2B (business-to-business) E-commerce, we and our business partners certainly don’t want strange new data elements and unpredictable files flying around, blowing up our applications or causing us to sift through error logs and data files trying to determine the source of the problem. Thus, we need some rules in place for which we will all abide by when constructing XML documents. You will recall in paragraph two, that one of the end results of the ALTA®’s EDI work was the publication of our industry X12 Implementation Guide(s). Each transaction set had specific structures, required records, data types, and code values which were to be adhered to when implementing that transaction set. In the XML world, the equivalent (at least for the time being) is the DTD (Document Type Definition). It is valuable both for using when you are first developing instances of XML documents for testing, and more importantly, it is used for run-time validation of XML files.
How Does it Work?
The DTD describes all of the elements that the document should contain, the order that they should occur in, which ones are mandatory/optional, which repeat, and so forth. An XML file will/may reference either an internal DTD (the DTD is actually included inside of the XML document) or an external DTD (one which is located externally on the network, Internet, etc.). When an XML file is received, a software application called an XML Parser will check first to ensure that the syntax of the XML document is well-formed (syntactically correct by XML specifications) and that the structure and content of the XML document adheres to the rules specified by its associated DTD (if it has one"a DTD is optional). (Note: DTDs do have a number of limitations and are probably only a temporary solution.)
Microsoft and Netscape provide an XML Parser with their browser. Also included with the XML Parser is one or more APIs (Application Program Interface), which provide a standard set of classes and methods to process XML documents. There are currently two APIs available for processing XML documents"the DOM (Document Object Model) and SAX (Simple API for XML). Developers can easily write code either directly into their applications or externally via a scripting language such as VBScript, Jscript, ASP, etc., to interface with these APIs and process the XML documents.
Okay, enough "techno-soup." What does this really mean? Well, in direct comparison to X12 EDI, you don’t have to purchase expensive translation software, spend time building maps between different file formats, or have X12 EDI expertise on hand. Developers can usually use a native programming language they are familiar with and the browsers, parsers, and program interfaces to process XML are already available.
So Where Are We Now?
As with the X12 EDI efforts, the mortgage lending/finance community has led the way early and have been both researching and beginning initial XML development efforts for the past year. Some individual companies, even longer. The Mortgage Bankers Association (MBA) last year formed MISMO (Mortgage Industry Standards Maintenance Organization) to facilitate real estate industry representation, participation, and standards administration functions for the ongoing development and maintenance of XML DTDs. Last year, a group called the XML Mortgage Partners teamed up with MISMO to provide them more than 50 DTDs which had already been initially developed for various mortgage lending/secondary market business transactions and datasets. DISA, the secretariat and U.S. data standards setting body of ANSI, has also stepped in this year to assist in MISMO’s efforts. The title insurance industry is represented by a Title Insurance Workgroup and ALTA®’s Kelly Throckmorton as governing chair within MISMO for title insurance initiatives. The various workgroups are in the most critical phase in XML DTD development"defining the architecture of the XML documents (what to use, how to use it) and gathering industry consensus on the creation of readable, unambiguous XML tags for business data elements. Giving folks a language where they can define their own vocabulary without giving them an industry-approved implementation could potentially be disastrous and would certainly exclude any sort of standard implementation by software vendors. The aforementioned groups include devoted commitment and participation of the largest of mortgage lenders, mortgage insurance companies, ancillary service providers and secondary market. External from the real estate industry, there are hundreds of other XML initiatives in virtually every business sector. At last count, more than 60 free XML tools were available through the Internet and software vendors are clamoring to enable their applications to be XML-capable.
So, here I sit, surrounded by mounds of paper data dictionaries, business scenarios, data flow diagrams, XML books beginning to draft sample DTDs and XML documents. I have no doubt that it’s starting all over again. I just find it somewhat ironic, that to develop a technology which will enable us to facilitate paperless transactions, the process begins with a mound of it.
Darren G. Ross is Director of Electronic Commerce at Stewart Information Services Corp. in Houston, TX. He can be reached at DROSS@landata.com or 1-800-729-1900 ext. 8482.