Next: , Previous: , Up: Top   [Contents]


2 Records

XML is a document markup language—it exists to describe data. It may seem odd, then, that Hoxsl defines—out of necessity—another way to represent data that is wholly outside of the structure of an XML document.

A sequence of items in XSLT can represent anything—nodes, processor directives, primitives, and others; some of these data cannot be serialized into an XML document and be de-serialized confidently without a great deal of effort and overhead. For schema-aware processors, this task is even more daunting, since an item can take on even more types. In certain cases, the task is impractical: consider maintaining the context of an element relative to its source document, such that axes like ancestor and preceding-sibling continue to work properly after de-serializing, and that the reference to the de-serialized node will continue be consistent throughout the entire system where the element may not have undergone serialization. Consider further using a deserialized element with document-uri.

The fool-proof method is to always keep XSLT’s representation of its own data in memory at all times without having to tamper with it. To do so, we must work with how XSLT represents all data: as a sequence. Sequences are like lists, but are one-dimensional:

<!-- Same as (1, 2, 3, 4) -->
<sequence select="(1, (2, 3), 4)" />

Figure 2.1: Sequences are always one-dimensional

In other words: there is no way to create structured sequences of arbtirary data. You can represent structured data as an XML element, which would be a single item in the sequence, but that reintroduces the serialization problem.

Passing large amounts of data on the stack is inherent in any functional system, and maintaining the integrity of those data is essential. Enter records.


Next: , Previous: , Up: Top   [Contents]