Jay Lofstead under the direction of Calton Pu

Size: px

Start display at page:

Download "Jay Lofstead under the direction of Calton Pu"

Jemima Berry
5 years ago
Views:

1 Literature Survey XML-based Transformation Engines Jay Lofstead under the direction of Calton Pu Abstract Translation has been an issue for humans since the dawn of communication. The advent of computers has neither lessened the need nor trivialized the task of translating. If anything, with the creation of incompatible computer protocols, the number of things needing translation, another word for transformation, has grown. The seemingly universal extensible markup language (XML) has been touted as the key to making these translation or transformation tasks easier. This paper is a literature survey of the use of XML for building transformation engines in order to generate background information for the author s current research, which uses an XML-based transformation engine. Introduction XML has changed the way organizations communicate electronically. In order to make communication in this convenient text format easier, standards have grown for how to encode data using the XML structure. Standards for data transformation are no different. The most successful early effort in encoding transformations in XML is clearly XSLT. Since its introduction, very few alternatives have been developed. Instead of making custom languages using the XML syntax, XSLT is typically employed. The performance issues are generally overlooked in favor of the widely understood format and wide availability of free tools to perform the transformation work. However, XSLT is not always the best tool for performing transformations. When looking for alternatives to XSLT, it is important to first understand the kinds of technologies that have been developed in the past. It is also important to remember the advantages XSLT brought and to incorporate them into any new language. There are three broad categories of XML-based transformation engines. The first category encompasses the most common situation. While not technically a transformation engine, XML has been deemed the transformation format for interorganization communication. A brief look at a few of the more interesting approaches will be examined. The second and most common group is the XSLT based engines. These all rely on having XML data and an XSLT file to describe how to adjust the data. In most cases, there are alternatives to using XSLT in these engines. The third class uses the XML standards, but is has opted for a custom approach instead of using XSLT. Following the survey will be a short description of how the author s current research compares with these tools and a section concluding the paper. XML formats as a Transformation Engine The most common use of XML for a transformation engine is not technically an engine at all. Instead, these are more examples of how XML is being used along with some application integration to provide the transformation services for communicating

2 For businesses, ebxml [7] provides a modular suite of standards for describing businessto-business transactions. As early as the 1960s, businesses relied have on Electronic Data Interchange (EDI) to communicate electronically with each other. While use of EDI grew, it was limited by the high costs for entry and the limited user base. Although EDI transactions can be more efficient by using compact, encoded, fixed width text formats with no markup, XML and the Internet have made a huge difference in the ability of businesses to participate in EDI transactions. In businesses with a mature infrastructure built around older-style EDI, the move to XML is less compelling. The less efficient format does not provide direct benefit to the organization. However, the need to communicate with businesses outside of the current EDI networks is forcing these businesses to adopt XML interfaces to continue to compete effectively. The ebxml suite of standards is providing the format for the XML messages once described using the EDI standards. The XML format is the transformation format with applications on either end of the connection formulating or parsing the XML message based on the private application needs. The actual work of interacting with the XML is left to the Similar to ebxml, G-XML [1], the Geographic Information Systems XML standard, provides an encoding of data in an application neutral XML form. Also similar to ebxml, while performance and data volume are concerns, XML was standardized as the format. Since the data is neither in a continuous stream nor in very large volumes, performance issues were deemed less important than the lower barrier to entry. For natural languages, XML and private transformation engines have been used for document transformation. These standards work from the idea that a document can be broken down into translation elements with markup to track each element in all languages. As changes are made to an element in one language, the corresponding elements needing new translation are tracked for more efficient multi-lingual document generation. While this is not the holy grail of translation, it is a good step to gain efficiencies in the translation process. Actual automatic translation of documents in an XML format would require complete markup of the structure and semantics of all of the text. The complexity and inexact results makes the incredible labor investment not worthwhile. For encoding documents to aid in multi-language synchronization, two standards have developed. First is Translation Memory exchange (TMX) [5]. It has fewer markup features, but provides support for more than two languages [17]. XLIFF [2] provides a richer framework for encoding the translatable elements, but is intended for bilingual use only [17]. Some of the translation tools support both formats allowing an organization to choose which format addresses each need. The key feature is the ability of the editor to work with a document in an editor seeing only the language they know and having the others be tracked automatically. Translators can see both versions simultaneously and adjust the out of date translations. One example of use for computing is the wxwidgets [3] toolkit. It provides a platform neutral and largely language neutral way of describing and creating user interfaces. There are libraries for C/C++, Python, Perl, among others and cross platform

3 implementations allowing the GUI to work properly on a very wide variety of platforms. These include Windows, DOS, PalmOS, Linux, and others. XSLT-based Engines The most commonly known XML-based standard for translating engines is known more properly as XSLT and frequently as simply XSL [4]. This technology did not grow in a vacuum, but was instead the outgrowth of previous standards for adjusting HTML documents. These previous two standards, DSSSL [9] and CSS [10], could not perform some desired operations, e.g., reordering elements, and were limited to transforming HTML documents [11]. The work of the XSL committee was to create the superset standard for XML documents, such as XHTML, mainly aimed at generating the technology now known as XSLFO (XSL Formatting Objects). As the work progressed, the early technology developed had the potential for being very useful on its own. Some participants saw an immediate need for a standard for transforming XML documents independent from the formatting system being developed. They pushed for the separate release of both XPath for element selection and this translation system that is now known as XSLT [11] to address their immediate needs. The committee later finished its work and released the full standard for formatting calling it XSLFO. The family of technologies the committee developed is collectively known as XSL. Given the wide availability of free XSLT engines, much of the work for performing transformations has been force-fit into using XSLT. A Google search for xml transformation will yield numerous examples. While XSLT works quite well for its target domain, text processing of an XML document, it is not a complete solution for transformation needs. One interesting example that works well is the Apache Cocoon project [16]. Cocoon provides a way to create web pages in an XML format that specifies the transformer to use based on the client type requesting the page. For example, a page is created in XML with elements listings which transformer to use for a web-browser client, a wireless client, a PDF reader client, or any other type imaginable. The base technology used for these transformation operations is XSLT. As one would expect, the XSLT code must be provided for each of these transformations. When XSLT is not the best tool, it is possible to integrate a custom transformation engine. Much like Cocoon, Morphis WAX [6] provides both a built-in XSLT translator and provides hooks for integrating a custom transformation engine. Unlike Cocoon, Morphis WAX is focused solely on developing wireless Many of the limitations of XSLT have been explored in [12]. While the paper focuses on semantic analysis, the limitations cited are of general concern. To address these limitations, a few standards for transformation using an XML-based approach have evolved for limited domain

4 Custom Engines Custom engines fall into two categories. First are those that use XML as the format to describe the actual transformation of the data. These technologies are characterized by having some XML technologies describing how to create one document type from another. The second category use XML to describe the deployment or interfacing of custom transformation elements. As mentioned above, some of the XSLT-based engines support integration of a custom transformation engine. This presupposes that the transformation can generally be done using XSLT in the first place. This is not always the case. XLE [8], the XML Lightweight Extractor, is based on the XML Document Type Description (DTD) [13] syntax to describe how to transform a relational database table into an XML format. The new format, known as DTDSA, only uses a subset of the standard DTD functionality, but has been extended for relational table to XML mapping. The limited domain of translating a relational database table has a severe limitation preventing the use of XSLT. In order for XSLT to be used, the data must first be in an XML format. Relational database tables generally use a custom format optimized for efficient manipulation rather than universal readability. The query processor must be able to efficiently manipulate the data and generate the desired output. The benefit of XLE is its universal application. Through the use of XLE, any database with a JDBC driver can have its output tables returned in XML format. Other vendors, such as Oracle, have opted to integrate XML output as a standard feature [14]. The Infopipes [18] project provides a convenient structure for specifying and using typed streams for transferring data using strict quality of service guarantees. Like so many other tools, the specification is written using XML. While some of the transformation systems use the XML to specify the actual transformations, Infopipes generally uses the XML to specify the composition of the transformations with references to external code to actually perform the transformation work. This external code can be either XSLT or a custom function written to work with the chosen underlying communication infrastructure. XChange XML-based Transformation Engine The author s current work performs translation of binary data streams through operations described in an XML file. This work was motivated from several different directions. First, the use of XML as the native transport format was unacceptable due to the data size growth typically involved. Second, performance is extremely critical. And third, because the data remains in binary form, a text-based approach is unworkable. The importance of using a well-defined XML syntax where possible to ease understanding was not overlooked. To address all of these issues, a new format and transformation engine was developed. The XML format uses declarative XML descriptions, but compiles down to a native machine language. The code is also built on top of a binary transport layer optimized for high throughput. Where possible, existing XML standards have been adopted as part of the system. For example, MathML was selected to generate the markup for mathematical operations.

5 Conclusion While various XML-based technologies exist for data transformation, the option generally falls into three categories. XML is used as the translation engine, XSLT transforms for translating XML documents or a custom, domain specific language and toolset using some portion of the XML standards. In all cases, the use of XML technologies to encode the transforms and/or the data is seen as a critical feature for the user base. References [1] Arikawa, M., Kubota, K., A standard XML based protocol for spatial data exchange - its capabilities and real International Workshop on Emerging Technologies for Geo-based Applications, May 21-26, 2000, in Ascona, Switzerland, [2] OASIS XLIFF TC. XLIFF 1.1. Retrieved from open.org/apps/group_public/download.php/3110/xliff-core-whitepaper_1.1- cs.pdf. [3] wxwidgets from [4] XSL Transformations (XSLT). W3C Recommendation 16 November [5] TMX 1.4b Specification. OSCAR Recommendation. 7 October [6] Morphis. [7] Electronic Business using extensible Markup Language. [8] XML Lightweight Extractor. [9] Document Style Semantics and Specification Language (DSSSL) ISO/IEC 10179:1996. Retrieved from [10] Cascading Style Sheets (CSS). [11] Covers, Robin. Extensible Stylesheet Language (XSL). Retrieved 28 November 2004 from [12] Karsai, G. Why XSL is not suitable for Semantic Translation. April Retrieved from _XML.pdf. [13] Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October Section [14] Oracle FAQ: Oracle and XML. Retrieved from [15] History of Ecommerce. Retrieved from [16] Apache Cocoon Project. [17] OASIS XLIFF FAQ. Retrieved from [18] Pu, C., Swint, G. Consel, C., Koh, Y., Liu, L., Moriyama, K., Walpole, J., Yan, W. Implementing Infopipes: The SIP/XIP Experiment, Technical Report GT-CC , College of Computing, Georgia Institute of Technology, May 2002.

The XML Metalanguage

The XML Metalanguage Mika Raento mika.raento@cs.helsinki.fi University of Helsinki Department of Computer Science Mika Raento The XML Metalanguage p.1/442 2003-09-15 Preliminaries Mika Raento The XML Metalanguage