The Ollin Project

Movement of Information

Abstract

For many, everyday work involves the maniplulation of information. To be shared, information must be commited to some media such as writing, images, of sounds. Each type of media has inherent strengths and weaknesses, and these are usually a function of the media's intended purpose. Media can be strategicly mixed to compensate for their individual limitations. Depending on how this is done, mixing may decrease the importance of the different media types, or it may only increase the number of media types required for effective communication to succeed. Regardless of the outcome, the proccess of mixing media makes constructing communication more complicated. This trade-off has to be weighed. Even though using the most appropriate media to communicate information has clear advantages, there are also advantages to using mixed media.

Information exists in programs in a variety of forms. Some forms are basic like numbers and strings, other are more complex such as arrays and objects. The structure of information in a program is dynamic, the information available at any given time can depend on scope. It is fairly easy to manipulate information within a program in the data types that are naive to the language it is programed in. As the use of XML increases, more and more programs need to get, store, or manipulate information in XML. Few languages have sufficient structures to make this integration with XML seamless. At best, most have an implementation of a Document Object Model to make XML easier.

Ollin is a set of XML languages designed to facilitate translation of program information into XML and vice versa. This can be used to supplement or replace existing input/output methods. Ollin is alternative methodology to the DOM.

Accessing XML: DOM vs.Ollin

XML is a meta-language, a specification for creating markup languages. Documents that use this language represent information in a structured and sematanticly rich format. Languages created with XML have several advantages and disadvantages. XML languages are human readable and can be hierarchical and structured. The amount of structure can be loose or strict depending on the need. The hierarchy can be simple or complex. XML is a very flexible specification and the languages it defines are diverse. XML provides an excelent platform for information interchange, but some overhead is required to parse and access the information in an XML document. A number of methods have been developed for accessing and manipluating information in XML.

The disadvatages of XML stem from the same features as the advantages, and most are simply trade-offs. XML is typically stored in a text file. This means it is human readable and accessible, but it also means that it is uncompressed. XML information can be compressed, encrypted for security, and even stored in searchable databases, but all of these processes add a layer of complexity to accessing the information. XML is not as consice at representing tabular information as a database would be, but it is much better for representing complex and irregular tree structures. Because XML is structured, XML documents must follow a specific format or they cannot be validated for use. There are a few simple rules all XML documents follow, the rest of the structure requirements are up to the author of a specific language. Languages with very strict structures can be frustrating to work with, but languages with ambiguous or amourphus structures can be confusing to author and difficult to extract useful information from. There is overhead associated with accessing any external information from within a program, but XML often has a little more overhead than other popular methods because of it's flexible nature. XML lends itself very well to "document" based applications, but is not nessicerily ideal for storing small, granular units of information when the hierarchy or structure per unit is simple.

Convnetionally, manipulation of XML information within a program is performed using a Document Object Model (DOM). This DOM is usually a set of functions or an object that provides a layer of abstraction between the program and the XML document. The advantage is less code, because the DOM does the "heavy lifting" and it can be reused. The disadvantage is there is a wide proliferation of DOMs. Each has it's own functions and most are language specific. Each DOM must be learned more or less individually. The funcitons for inputing and outputing XML are usually straightforawd, but the functions to manipulate or access information in XML are usualy more complex and varied. There is also one problem that a DOM does not solve. Each program that uses a DOM has code that is very specific to the XML language and DOM being used. If the structure of the languages changes, code must be changed. If the need to input or output a different XML language arrises, code must be changed. If the DOM changes, code must be changed. More code must be written as the number of XML languages being used increases. All of this code can, at best, be separated into functions or objects and managed separate from the program's main fucntionality, but this only simplifies the programmer's task slightly. More code means more work.

Ollin attempts to provide an alternative to the DOM model. Clearly there are some cases where a DOM makes sense, but at other times it is easier and more efficient to create a map from an XML language to the data structure a specific program uses or vice versa. This simplifies the code for getting information to and from XML and can eliminate the need to manipulate an XML document using a DOM. Instead, information can be manipulated internally by the program in whatever data structures are most effecient and then translated back into XML. In general, performance differences between the Ollin methodology and the overhead of a DOM should be negligable, though each process would be optimal in certain situations. The Ollin languages take code out of the program and do the work in XML. Depending on the programmer's desire to work in XML this can be a plus or a minus. Ollin provides a more consice and programming language independant map of structure in XML to more program centric structures.

The Structure of Ollin: Ixtli and Yollotl

Within the project three types of languages are defined. The super-set, Ollin, includes all features needed to perform bi-directional translation of information from program data to XML and back. Features that translate program data into XML are in set called an Yollotl language. Features that translate XML into program data are in a set called a Ixtli language. Features that do not fit into these two catagories include those that handle batch processing of multiple documents (for input or output), processing of a portion of a document, multiple layers of transforms, or other orchestrated functions. These features are available in an Ollin language. These three languages are defined seperately because in some cases bi-directional translation is not needed. If only Ixtli or Yollotl are needed, the number of tags used in translation document are relatively low. Ixtli-only and Yollotl-only parsers are also relatively simple. Ollin includes all features of Ixtli and Yollotl, so when full blown processing is needed all three act as one language.

At this early stage there is no specific language proposed for each of the three laguange type. There is a lot of new development in language methodology and rather than run with languages which may not be ideal, the intenion is to allow multiple languages to be developed and derive the master Ollin, Ixtli, and Yollotl languages from them. Currently, XATL (XML Array Transform Language) is being developed as a prototype for Yollotl.

The concepts of Ollin, Yollotl, and Ixtli are borrowed from Aztec culture and the Nahuatl language. Ollin means change or movement, a transition. Yollotl is a symbolic term meaning one's heart, the dynamic nature of humans. Ixtli is a symbolic term meaning one's face, the persona projected by an individual. Yollotl is a natural trait and so it is used to describe data in it's "natural state" inside a program. A Yollotl parser takes program data and a map and outputs XML. Ixtli is a sociological trait, one that it is learned. Ixtli represents data in the form that is can be shared with others, the "face". An Ixtli parser takes an XML document and maps it into program data. These terms form the base of the metaphores used in the project.