Next: , Up: Records   [Contents]


2.1 Design Considerations

Introducing, effectively, a new type system into XSLT should be done cautiously and faithfully —it should work with the language, not sneak klugily around it. The main considerations are:

  1. Records must be able to contain any number of arbitrary key-value pairs;
  2. Value data must be passed by reference (consequently, unmodified), for both reasons of performance and data integrity;
  3. Templates and functions must be able to return any number of records as part of a sequence;
  4. Record must be able to contain sequences as values and, consequently, other records;
  5. Templates must be able to match on record types and record values must be able to be queried within XPath expressions, so as not to disrupt XSLT conventions; and
  6. Records should incur a nominal performance penalty relative to the actual application logic.

Each of these properties will be addressed as they are introduced in the sections that follow. But the fundamental concept that needs to be considered before even beginning an implementation is the viability of sequences.

Sequences are generally performant: when you execute an XPath expression on a document yielding multiple matches, each item is returned as part of a sequence. These sequences could potentially yield tens of thousands (if not more) of results. You can then refine those results using further XPath expressions, looping constructs, template applications, and functions. This is important when we consider records, since records could be of arbitrary length, recursively.

A record, then, is nothing more than a slice of a sequence —it must have a defined length to state how many items within the sequence “belong” to the record, but it otherwise does not need to define much else, since XSLT’s type system handles most of that work for us.1

Consider some record named Rect that contains two fields A and B, both of type Point, where the record Point contains two fields x and y. Let x and y be represented by xs:integer; we could represent two rectangles using the following numbers:

(..., 0, 1, 1, 0, 2, 2, 4, 0, ...)
       \/    \/    \/    \/
       A1    B1    A2    B2
         \  /        \  /
          R1          R2

Figure 2.2: Representing two Rects R1 and R2 as a sequence of xs:integers

The goal of a record implementation is to determine how we represent each of the records in Figure 2.2, where those items could exist in a sequence of any other arbitrary items. The implementation will involve adding additional items into the sequence in order to provide the needed context.

Note: records are implemented without the use of Hoxsl’s higher-order functions; those functions are backed by records, so we’d have a bit of a chicken-and-egg problem.


Footnotes

(1)

Remember: the original goal was to stay as far away from data manipulation as possible.


Next: , Up: Records   [Contents]