Hendon Publishing - Article Archive Details

Print Article Rate Comment Reprint Information

The LEXS framework: A leap forward in interoperability

Written by Aaron Gorrell

The relative ease of developing data standards using XML Schema has resulted in significant issues for integrated systems. For every data exchange defined and implemented, there must be custom software written to validate and consume the information. The consequence is that implementers must constantly develop “one off” versions of their software to support all of the variations in user data requirements. To help address this issue, the people at the DOJ’s Law Enforcement Information Sharing Program (LEISP) have come up with an innovative solution called the LEISP Exchange Specification (LEXS).

LEXS consists of two schemas that provide different but highly related services. LEXS Search and Retrieval (LEXS-SR) provides a mechanism for system-to-system federalized queries and responses. On the other hand, LEXS Publication and Discovery (LEXS-PD) provides a highly refined means to organize the structure of any IEPD developed to transmit sharable business information between two systems. It is LEXS-PD that is the focus of this article. For readability, we will henceforth refer to the LEXS-PD simply as LEXS.

LEXS does not define yet another XML data model—rather, it builds upon the component-based structure that is inherent in NIEM 2.0. Its purpose is to define a sophisticated template for NIEM-based XML Schema. Heretofore, most of NIEM-based schema has been grab bags of XML elements and types arranged in often seemingly random ways. LEXS breaks this paradigm (or perhaps this lack of a paradigm) by splitting the message definition into several discrete parts. This approach facilitates a greater degree of code reuse while allowing implementers flexibility in determining how much of the message they want to understand. The tightly defined nature of a LEXS-based message also lends itself to the “network effect” where the cost of implementation reduces dramatically with every implementation.

“Like anything with value deriving from a network effect, the benefit may not be apparent early on,” said Jeremy Warren, chief technology officer, USDOJ. “How valuable was the telephone when only three people had one? But the payoff going forward is huge…LEXS is the only thing out there that can offer this network effect in information sharing, and we are working hard to grow the implementing community as fast as possible.”

How Does LEXS Achieve This?
To understand how LEXS accomplishes this task, we first need to understand the structure that LEXS applies to XML Schema. The concepts behind the LEXS framework are based on the assertion that NIEM-based schemas typically share a sizable percentage of common XML elements. For example, an arrest report, an incident report and a traffic citation all contain key information about a person, a vehicle and a location. LEXS leverages this concept by creating a pre-defined place in which to put this “common” information. Any time the data requirements indicate the inclusion of this information (as well as many other common types), the information is placed in this common area called the digest. Information that is specific to a particular document or a jurisdiction is included through the extended portion of the LEXS message called the payload.

• Digest: The digest contains core information that describes key characteristics of common objects (such as the person, vehicle and location described above). The contents of the digest are pre-defined by the DOJ and can stand alone or be used in conjunction with the payload to hold additional information. A primary rule for being LEXS compliant is that the Information Exchange Package Documentation (IEPD) does not make ANY change to elements defined in the digest.

• Payload: The payload defines all those elements that cannot be placed in the digest. It is similar to an extension schema and will typically vary between schemas. For example, although information about a person charged with a crime can be put into the digest, a list of the actual charges against that person must be located in the payload. The contents and structure of this payload is defined in a separate XML Schema file.

Benefits
Because the information that can be contained within the digest does not vary between IEPDs, a single “LEXS-enabled” application can be developed and used to consume the digest portion of any LEXS message. For example, if ACME RMS Software develops the software necessary to create an N-DEx message, that same code can be used to populate the digest portion of any other LEXS-based message. Likewise, there is benefit for receiving systems. A LEXS-enabled receiving partner system should always be capable of consuming the digest and (presumably) store its content in a database. LEXS allows the implementer to handle the payload in a number of ways, depending on their business requirements:

1. Consume: If the receiving partner needs to utilize the information contained in the payload in a structured way (such as to allow the system to determine workflow), he must write new software to consume the payload. Of course, the software written to consume the digest is usable across all LEXS-conformant messages.

2. Store: The receiving partner may choose to store the payload in its native XML-format. This eliminates the need to write the software to parse and consume the structured elements within the payload. Increasingly, a number of database vendors now provide the means to query XML formatted data, thus still making the information available for extraction. Interestingly, the contents of the payload may still be made visible to the user by leveraging a capability of LEXS called rendering instructions (more on this in Part 2).

3. Ignore: The receiving agency may not have a need for the information contained in the payload and can disregard it.

Who Should Consider Using LEXS
Virtually all organizations and disciplines can benefit from an understanding of the LEXS structure. The specification uses many advanced XML techniques that would benefit any IEPD. For example, LEXS delves deeply into implementation with a comprehensive set of metadata elements that provide information about the sending agency and the message itself. Three classes of users particularly stand out as being able to derive exceptional benefit from a LEXS-based implementation:

1. RMS Service Providers: The holy grail of any commercial off-the-shelf technology solution (COTS) is maximizing reusability and minimizing “one-off” solutions. Using LEXS, service providers can write and reuse the same code to deal with an estimated 60% to 80% of the elements they are likely to share.

2. Law Enforcement Agencies: Agencies should be able to realize the benefits of standardization among RMS vendors through lower costs and expanded business functionality. Similar benefits can be achieved in other systems that agencies support such as property management, intelligence and mobile display terminal (MDT) systems.

3. LEA Exchange Partners: As the court and other LEA exchange partners receive more LEXS-based messages, they will also benefit from the network effect.

No Silver Bullets…
One potential downside of LEXS is the up-front costs that can be anticipated in implementing a LEXS-based framework. Part of this cost is the considerable learning curve associated with working with LEXS. LEXS changes the way NIEM-based XML schema is developed and implemented. As such, the challenges commonly associated with leveraging paradigm-shifting technologies can be expected among both the business and technical staff. Some of the other challenges that can be expected include the following:

1. Bifurcated Objects: Certain information pertaining to a single logical object may need to be split between the payload and digest. This issue can be best illustrated with a person name such as “Hank Williams Jr.” The first and last names are captured in the digest. However, the suffix name of “Jr.” must be contained within the payload because the digest does not incorporate the elements for a person’s suffix name. LEXS links these kinds of split objects through an XML element called the SameAsDigestReference.

2. Two-Pass Validation: The contents of the payload and digest are defined within two separate schemas. As such, these two portions of the instance document must be validated separately. Generally, this is accomplished by using software to split out the payload portion of the message into a separate file and validate that file against the payload schema. Validating the digest portion does not require any additional steps. Typically, this is only an issue during development because most implementations turn off validation for their production environment. You can download and view a demonstration of software that automatically splits and validates LEXS-based messages at www.waterholesoftware.com.

3. Documentation: Comprehen-sive XML examples are a best practice for all XML specification development. Given the complex nature of LEXS, thorough documentation and examples are even more important.

In the beginning, the benefits and concepts will typically resonate, and organizations will take up the LEXS mantle with enthusiasm. However, as their first attempt moves toward implementation, this enthusiasm will often be followed by frustration and aggravation as they are faced with new types of issues and challenges unique to the LEXS framework. But these issues have been confronted and handled in organizations implementing the LEXS framework (both within and outside the DOJ), and a nascent LEXS user community is starting to develop, which should further reduce the knowledge gap.

Follow Through
More information about LEXS can be downloaded from
http://www.it.ojp.gov/jsr/common/viewDetail.jsp?sub_id=256&view=yes&keyword=1. It includes a user guide, which thoroughly describes the structure and usage of LEXS, as well as the LEXS schema. The NIEM Help Desk is staffed to help answer LEXS questions and can be used as a further resource. Finally, I welcome any questions or inquiries regarding LEXS-based technologies and can be contacted at the following e-mail address.

Aaron Gorrell is president and CEO of Waterhole Software, a firm that specializes in the development of robust system archi- tectures and specifications for justice organizations. He can be reached at aaron.gorrell@waterholesoftware.com.

Published in Public Safety IT, May/Jun 2008

Rating : 10.0


Comments

Comment on This Article

No Comments


Related Companies

Waterhole Software
 

Related Products

InteroperabilityXML Schema
 

Events and Tradeshows: LAOPFMTRPSIT
Latest News: LAOPFMTRPSIT
 
Close ...