Often the question with new technologies is how should the technology be used, when should it be used, and what will be the expected impacts of the new technology.
The W3C working group developed two documents to assist decision makers in assessing such concerns titled Efficient XML Interchange (EXI) Best Practices (W3C, 2007) and Efficient XML Interchange (EXI) Impacts (W3C, 2008).
1. Domain Applicability
Because EXI is centered on the traditional XML Infoset, it is applicable to any XML domain, but can deliver varying degrees of efficiency and compactness based on each domain’s specific design characteristics (W3C, 2008). EXI’s is applicable to any domain whenever native XML cannot support the domain’s efficiency and compactness requirements. However, EXI does not need to be implemented within domains that do not benefit from its strengths.
Domain-cases that are likely to see the least improvement from EXI are those that use unique characters or custom octets such as base64 characters.
2. Human Readable
To address the demand to retain the human-readable format property of XML, the recommendation is to let a tool do the translation transparently to the user. Few people truly edit XML documents outside of an XML-specific editing tool environment.
Therefore, let the editor read and write EXI, but present traditional XML text to the user of the editor tool. Retain the human readability of the underlying XML file by enabling the tool to switch between XML and EXI. While the user loses the ability to use a plain-text-editor, they can still use an XML-specific editor. This is not a handicap if the compressed EXI document remains ungarbled and correctly formatted.
3. Domain Optimization
Depending on the implementing domain, pruning options can be used to eliminate excessive and unnecessary information from an XML document. This approach
increases efficiency and delivers a more compact file. Often a domain is only concerned with specific portions of a document, and all the metadata and header information is syntactically irrelevant, though required for the XML structure or the human-readability.
EXI content optimization through fidelity options enables higher efficiency and compactness; however, this comes at the cost of lossy compression.
4. Security and Signature
The method to secure information across the Web is digital signature and
encryption. EXI is capable of supporting both without modification, but with a few EXI-specific warnings depending where within the signature-encryption chain EXI is applied.
a. Output Alignment
If EXI is implemented before either the signature or encryption of the XML document, and assuming the EXI results are placed within another XML document, the EXI encoding options for byte-alignment must be set because both signature and encryption operate on octets (bytes). As shown in Figure 24, if EXI is byte-aligned, the EXI compression technique can be applied on fragments of XML in-between signature and encryption (Williams, 2009).
However, if the XML document is compressed with EXI after signatures and encryption, then the alignment of EXI output is not of concern. Both XML-signature and XML-Encryption output valid XML, although with blocks of base64 data. All EXI requires for operation is a valid XML input document, which both signature and
encryption produce. However, signed and encrypted XML documents will not compress well with EXI due to the high volume of pseudorandom high-entropy base64 data.
Figure 24. EXI Integration with XML Encryption and Signature (From Williams, 2009)
b. XML Signature
Digital signature operations require a predefined (sender and receiver agreed) canonicalization of the XML document. The XML specification for digital signature requires the inclusion of a canonicalization method element as part of the metadata describing the signature, and is used to verify which XML Infoset items it can ignore and how it should handle namespaces. Since the XML canonicalization methods are identified by URI (namespace), the EXI specific options of Preserve.pis,
Preserve.prefixes, and Preserve.lexicalValues, and optionally Preserve.comments are required to be set to “True” before encoding XML to EXI for follow on digital signature.
c. XML Encryption
Encryption requires the data to be removed from the Infoset prior to encryption. This is because the first occurrence of each string under EXI is output to the EXI file in raw ASCII format. XML defines procedures to replace elements and their content with a new element containing a cipher and metadata describing how the cipher was generated. This replacement process transforms the XML into octets, in base64.
Often, though not required, a XML canonicalization method is used to produce these octets to reduce the amount of contextual information being encrypted.
5. Domain Integration
a. Web and HTTP Servers
EXI is optimally suited for Web-content and Web services within low-bandwidth environments to enable XML to domains previously unable to support native XML. Ed Day (2007) of Objective Systems Inc, a developer of open standards that promote the interoperability of systems was quoted, “We are trying to expand the Web by getting XML into places where it could not be used before.” This goal is most widely accomplished by deploying implementations of EXI into HTTP server environments.
b. XML Modifications Considerations – Schema Mandate EXI is designed operated on the XML families of technologies without modification or disruption to the XML already in existence. However, with the future in mind, and optimization taken into consideration, certain XML infoset modifications might enhance the impact of EXI, such as a descriptive schema requirement for all XML documents.
c. Initial EXI Distribution
Because the adoption of EXI will initially be sparse, care must be taken to ensure data exchanges in the EXI format are between EXI enabled systems. To ensure interoperability during initial EXI adoption, it may be prudent to exchange both native XML formatted documents as well as EXI versions whenever EXI compliance between systems is uncertain.
E. CHAPTER CONCLUSION
EXI was not arbitrarily recommended by the W3C for standardization; it was thoroughly tested against numerous criteria and techniques. Each time EXI proved to be the most optimal choice. EXI has proven to be a valid and preliminarily verified solution
Characterization (XBC) working group. Compared to all other candidates, EXI proved to have the best compactness, efficiency, and accuracy for a standardized binary XML format.
F. CHAPTER SUMMARY
This chapter discusses the testing framework used by the W3C to evaluate candidate compact binary XML formats. The nine candidate techniques are discussed along with their summary of results, with the Efficient XML Interchange (EXI) technique being the superior and chosen method for continued standardization development. EXI is further analyzed by comparison with the industry standard GZip technique. The chapter concluded with the W3C’s preliminary recommendations for EXI implementation and usage.
VII. OPENER-EXI IMPLEMENTATION RATIONALE
A. INTRODUCTION
This chapter discusses the administrative constraints and challenges an EXI implementation will face in terms of licensing, deployment, and DoD specific integration constraints. Specific examples throughout this chapter are made in regards to OPENER-EXI, the NPS open source partial implementation of the EXI specification. The goal of this chapter is a set of recommendations for EXI development and deployment that will deliver the deepest and fastest adoption of OPENER-EXI or other EXI solution into existing network architectures.