Readers are expected to have at least a basic knowledge of XSLT. The following resources might be a good place to start: XSLT 1.0 W3C Recommendation; D. Pawson's XSLT FAQ..

By content logic, we mean the XSLT code that produces the actual text and data (the content) which compose an AIP. For example, a section title is marked up as such in the XML eAIP document and is copied into the generated HTML and XSL-FO documents, possibly with an automatically-generated numbering. In this case, some content logic may be needed to compute the title numbering.

By presentation logic, we mean the XSLT code that produces the formatting and styling necessary to present the content on the target format (HTML, XSL-FO and others). Continuing with our title example, the title content is typically surrounded by formatting mark-up such as a h1-h6 element in HTML or a block element in XSL-FO. These elements would possibly contain styling mark-up such as a class in HTML and font-related attributes in XSL-FO. Output of these elements and attributes is part of the presentation logic.

Presentation logic is specific to each target format, while content logic can generally be re-used for any format. Still with our title example, the numbering computed by the content logic is exactly the same for HTML and XSL-FO. In fact, it should probably be the same for any target format, because numbering is considered to be part of the content. Even though the AIP editors marked the title to be automatically numbered, the number produced must be the same for all target formats.

The style sheets are split in 3 groups:

In order to separate as much as possible content from presentation, the XSLT code was split in three parts. Most elements are handled by two or three templates. For the sake of this documentation, let's call them "the matching template", "the presentation template" and "the content template".

In general, templates will only process one element or one attribute (though presentation templates might generate several elements and attributes as needed). Therefore, attributes may have their own set of three templates.

The Designated-point element gives us a complete example:

There are three "main" style sheets: html-content.xslt for HTML pages, html-menu.xslt for the HTML Navigation menu (ToC) and fo-content for FO files. These 3 files import many other files, which handle specific groups of eAIP elements.

The following table shows which XSLT file handle each element.

The XSLT code which builds route tables in ENR 3.1 to ENR 3.5 was originally developed "by example", i.e. by closely following the ICAO AIP Specimen. This may seem too restrictive sometimes, but can be changed: These restrictions are only present in the XSLT transformations and not in the DTD. Specifically, the following rules are implemented:

The eAIP DTD features a class attribute on every elements, with the objective of separating presentation from content. When an element needs a specific styling, the editor gives a name to this styling and use it in the class attribute. This name is then used in HTML and XSL-FO transformations to look for the corresponding style definition.

For XHTML, the transformation is rather straightforward: the class name is simply copied to the XHTML file generated. The style definition are located in a CSS file named eAIP.css.

In XSL-FO, there is no way to define classes externally: all styling has to be defined as attributes on XSL-FO elements. So, our transformation converts class names to XSLT attribute-sets elements, which are applied to XSL-FO elements. Attribute-sets are defined in the file fo-styles.xslt.

However, a limitation of XSLT imposes that attribute-sets are used statically. That is, a transformation is supposed to know in advance the name of an attribute-set it uses. We sometimes have static attribute-sets, when we use the default class name for a given element. For example, an Address element is formatted using the Address attribute-set. Here is its presentation template (amendment processing removed for clarity):

But, when we need to convert the class name declared in a class attribute, this is of course not possible and we then need to apply an attribute-set dynamically. The following is illegal XSLT code:

There are three known workarounds, as explained by Jeni Tennison in an email on the XSL-list mailing list titled "Re: [xsl] using variable as a value for "use-attribute-sets"". We have chosen the second solution, which basically consists in parsing our fo-styles.xslt file from within our transformation, just like any other XML file, and use it as our data source for class names to attribute-sets conversion. This trick is implemented in the file fo-att-set.xslt. We expanded Jeni Tennison's example so that variables and parameters are processed and attribute-sets can use other attribute-sets.

The following template, taken from fo-att-set.xslt, shows the generic handling of the class attribute:

Note that in most cases, this template is not actually used, because the value of the class attribute generally needs to be combined with other classes.

A class name is defined as follows in fo-styles.xslt:

The class Left-region-body is implemented by the attribute-set of the same name. This attribute-set uses another attribute-set, region-common, which sets more attributes, common to Left-region-body and others. Left-region-body's attributes make use of variables, also defined above.

There are some limitations in our implementations:

It is possible to overcome these limitations, but we don't need it so far.