The EADMapping Table

As of v5.1, Aeon supports the use of multiple XSLT files when processing EADs. The EADMapping Table is the tool used to configure the rules that the Aeon DLL will follow when evaluating which XSLT file to use for a given EAD. This feature enhances the EAD processing engine by allowing you to provide custom solutions for any EADs with significantly different processing needs. 

The EADMapping Table

The EADMapping Table is located in the Customization Manager at Web Interface | EAD | EADMapping and contains the following fields:

Behavior

When a request is made from an EAD, a link for that EAD is sent to Aeon for processing in the following format:

aeon.dll?Action=10&Form=31&Value={url to EAD XML file}.

The DLL will apply the rules defined in the EADMapping table to evaluate this information and determine which XSLT file to use for the EAD in the following manner:

1. Records will be retrieved from the EADMapping table and evaluated in ascending sort order (starting with the lowest number) using the values defined in each record's Sort Order field. 
2. Each EADMapping record will be applied to the EAD in the following order:
   1.  If the record contains a value for the URI Match String field, that regular expression will be applied to the EAD URI (the URL in the 'Value' query parameter shown in the example above). If it matches, the XSLT file specified in the Collection XSLT File Name field for that record will be used.
   2. If the record contains a value for the XPath Match String field, that XPath expression will be applied to the content of the EAD file. If it matches one or more nodes, the XSLT file specified in the Collection XSLT File Name field for that record will be used.
   3. When evaluating XPath expressions in the XPath Match String, the Aeon DLL will use the namespaces specified in the Namespace field, if provided (see Namespaces section below).
   4. If neither match string matches the given EAD, the Aeon DLL will move on to the next record.
3. If no matches are made to any of the records in the EADMapping Table, Aeon will use the default 'aeon.xslt' file.

Namespaces

Some EAD files may declare XML namespaces, which must then be used when matching EAD elements with XPath expressions. Namespaces can be declared anywhere in an XML file and will apply to the element on which the namespace is declared, as well as any of its child elements. In practice, this means that you'll most often find namespaces defined on the top-level element of the XML file (i.e. ead). If a namespace is declared for an EAD element, then that namespace must be defined in the EADMapping record's Namespace field in order to match the element with any XPath expressions defined in the XPath Match String field. 

Namespaces are declared in the XML file with the "xmlns" attribute in one of two ways:

• Named namespace: A namespace that has an identifier or "name" directly after the xmlns attribute.
  • For example, 'xmlns:xlink="http://www.w3.org/1999/xlink"' declares a namespace with the name "xlink".
• Default namespace: A namespace with no identifier or "name" directly after the xmlns attribute.
  • For example, 'xmlns="urn:isbn:1-931666-22-9"' declares a default namespace.

Declaring Multiple Namespaces for a Single Record

To declare multiple namespaces within a single record, separate each entry in the Namespace field with a space. For example:

 xmlns:e="urn:isbn:1-931666-22-9" xmlns:xlink="http://www.w3.org/1999/xlink"

Example Cases

The example cases detailed below will help clarify when to use an URI Match String rule vs. an XPath Match String rule when creating a new entry in the EADMapping Table, and how to set the appropriate field values for each. 

Example 1: Setting an URI Match String Rule

In this example, a site's EADs are generally processed correctly by their default "aeon.xslt" file, but there are a handful of collections in their music library that are different enough that it is necessary to apply a different XSLT called "music.xslt" when processing requests for these items. In this case, the URLs for these collections are located together under a folder on the server, "http://university.edu/eads/music/{filename}.xml".

Since the files for these items are all in the same location, the site can write an EADMapping record that matches these EADs using the URI Match String field and applies the "music.xslt" through the Collection XSLT File Name field as follows:

Example 2: Setting an XPath Match String Rule

In this example, as with the previous case, a site's EADs are generally processed correctly by their default "aeon.xslt" file, but there are a handful of collections in their music library that are different enough that it is necessary to apply a different XSLT (music.xslt) when processing those requests. However, in this case, the EADs for these collections all have an EAD ID element that contains the text "music-library":

<eadid countrycode="us">univ-music-library-bach</eadid>

Since each collection contains the text "music-library" in its EAD ID, the site can write an EADMapping record that matches these EADs with the XPath Match String field as follows:

Example 3: Setting an XPath Match String Rule with a Namespace

In this example, the case is exactly the same as the previous example, except that this time the EADs for the collections in the music library additionally declare a default namespace in the format, 'xmlns="urn:isbn:1-931666-22-9"'. Since a namespace is declared in the XML file, the site will need to add values to both the XPath Match String and Namespace fields in the EADMapping rule in order to match the EADs in this collection by the value in the XPath Match String field. 

Furthermore, because the namespace declared is a default namespace, a name must be declared for it in the Namespace field (in this case, "e" is the chosen name):