Balisage Paper: Meta-stylesheets: Exploring the Provenance of XSL Transformations

Introduction

Provenance records are records for trust and authenticity, records to prove that the object is what it is claimed to be. Provenance has its roots in the archival world, where the goal is to see objects survive with minimal weathering as they pass from one caretaker to the next (Sweeney, 2008). Similarly, data provenance answers the question "How did this come to be here, in this state?", and it does so by identifying the agents, transformation events, and other artifacts associated with that object.

Computer usage is so prevalent in humanities and sciences research that it is all but guaranteed that data will be changed in some way during its lifetime. This has the advantage that tools can automatically generate provenance information, recording important details about the transformation process. Later, a provenance record of this sort may be used for error-checking, to independently reproduce a result, or simply for results verification (Küster, Ludwig, Al-Hajj, & Selig, 2011). Few e-humanities software tools offer provenance capabilities, likely due to time constraints and a lack of common practice. However, one reason may be in terms of nomenclature. Humanities research often involves documents, and humanists may bristle to think of their documents as the 'data' part of data provenance (Fear, 2011).^[1]

Still, more and more documents are becoming - or are born as - data, thanks to mark-up languages (Buneman, Khanna, & Tan, 2000). XSLT is one possible step in document transformation, and as such, is subject to the same provenance needs as other processes. XSL transformations can be examined and, with a little effort, used to generate provenance information about the creation of documents. The goal of this project is to examine methods of gathering provenance information about XSL transformations, and to explore the possibilities of automatically generating such records.

Provenance terminology

A handful of provenance ontologies exist, and each identifies three basic classes of provenance: information about processes, or transformation events; about agents, or the people (or software) which catalyze or carry out the event; and artifacts, or 'things' which may be acted on, generated by, or otherwise associated with a transformation event. The below figure gives the terminology of two such ontologies, the Open Provenance Model (Moreau et al., 2010) and the W3C PROV-O (Belhajjame et al., 2012).

My first attempts at provenance documentation were founded on the XML binding of OPM. OPM was designed primarily to capture information about scientific data workflows, and loosely fit the information needed to document XSLT provenance. Current work makes use of the Open Provenance Model Vocabulary, a modified version of OPM which includes a module for XSLT provenance (Zhao, 2010). As such, this paper makes use of OPM and OPMV XSLT module terminology.^[2]

What can we glean from an XSL transformation?

Gathering XSLT provenance information is already possible through a number of methods. The simplest method (though not necessarily the easiest for understanding) is to simply examine the artifacts associated with an XSL transformation - mainly the input, output, and stylesheets involved in the transformation. In particular, comments left on a stylesheet could reveal the author agent's identity, thought process, and understanding of what the XSLT code does or is supposed to do. One might be able to determine the templates' firing order, but the process may just as well be laborious in terms of piecing together provenance.

A better method is to use a debugger to step through a transformation, which grants an in-depth look at the way an output document is constructed from input and stylesheet. Parameter and variable values may also be shown, which may explain choices made by the XSLT processor. This step-through method is aimed for human understanding, but no record of the steps is available for consultation. Provenance information would be easier to identify with this method as opposed to the first, but it would still have to be documented by hand.

In contrast, the Saxon processor has a trace function^[3] which provides a tree view of the steps within an XSL transformation. It shows what input nodes are matched to templates, and includes the file name and line numbers of each processed node. The trace log cannot reference the specific elements in the output that came into existence due to any one transformation step. Instead, one must infer the structure of the output from the steps taken. Still, when used as a roadmap to examining the input documents and stylesheets, the trace log is explicit and exact in its references - a good representation of the transformation which created the output, so long as one has access to the files referenced.

<trace saxon-version="9.4.0.3" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <source node="/" line="0" file="test1.xml">
  <xsl:template match="/" line="16" module="testRegStylesheet.xsl">
   <LRE name="html" line="17" module="testRegStylesheet.xsl">
    <LRE name="head" line="18" module="testRegStylesheet.xsl">
     <LRE name="title" line="19" module="testRegStylesheet.xsl">
      <xsl:text line="19" module="testRegStylesheet.xsl">
      </xsl:text>
     </LRE>
    </LRE>
    <xsl:apply-templates line="21" module="testRegStylesheet.xsl">
     <source node="/test/compute[1]" line="3" file="test1.xml">
      <xsl:template match="compute" line="26" module="testRegStylesheet.xsl">
       <LRE name="body" line="27" module="testRegStylesheet.xsl">
        <xsl:apply-templates line="28" module="testRegStylesheet.xsl">
         <source node="/test/compute[1]/message[1]" line="3" file="test1.xml">
          <xsl:template match="message" line="33" module="testRegStylesheet.xsl">
           <xsl:call-template line="34" module="testRegStylesheet.xsl">
            <xsl:value-of line="36" module="testRegStylesheet.xsl">
            </xsl:value-of>
            <xsl:template name="summon" line="42" module="testRegStylesheet.xsl">
             <xsl:param name="sayeth" line="43" module="testRegStylesheet.xsl">
             </xsl:param>
             <LRE name="b" line="44" module="testRegStylesheet.xsl">
              <xsl:text line="45" module="testRegStylesheet.xsl">
              </xsl:text>
              <xsl:value-of line="46" module="testRegStylesheet.xsl">
              </xsl:value-of>
              <xsl:text line="47" module="testRegStylesheet.xsl">
              </xsl:text>
              <xsl:value-of line="48" module="testRegStylesheet.xsl">
              </xsl:value-of>
             </LRE>
            </xsl:template>
           </xsl:call-template>
          </xsl:template>
         </source><!-- /test/compute[1]/message[1] -->
        </xsl:apply-templates>
       </LRE>
      </xsl:template>
     </source><!-- /test/compute[1] -->
    </xsl:apply-templates>
   </LRE>
  </xsl:template>
 </source><!-- / -->
</trace>

XSLT itself also provides the capability to capture some provenance information, through functions such as system-property() and base-uri(). With these functions, the output of a stylesheet could include information on the XSLT version used; the processor agent which controlled the XSL transformation; and the file names of an input document and the primary stylesheet. However, the use of this method is dependent on those who created or who maintain the stylesheet.^[4]

The oXygen XML Editor has a documentation generation tool for XSLT stylesheets. The tool creates a log giving information about the stylesheet and children of the xsl:stylesheet node (most notably, templates). Interestingly enough, the documentation tool also assumes that if a node has a comment placed immediately before it, then the comment is documentation for the contents of that node. While this assumption could be wrong, it certainly rewards those who provide descriptions of stylesheets and templates through comments. It is worth noting that the documentation tool may not contain any provenance information at all, since it only describes the stylesheet artifact and does not guarantee any references to agents, process instances, or other artifacts. On the other hand, the documentation is an excellent example of the types of information that should be included when a provenance record references a stylesheet or template artifact.

What kinds of information, then, can we find about an XSL transformation?

The meta-stylesheet method

A workflow for provenance reporting

The steps of the XSLT provenance workflow are currently as follows:

1. Use the meta-stylesheet to create stylesheet B (for generating provenance) and, optionally, stylesheet C (for assigning rdf:IDs to template code)

2. Use stylesheet A or C^[5] and input.xml to create output.xml^[6].

3. Use stylesheet B on input.xml to create an OPMV RDF graph representing the provenance of step 2.

Figure 3: An overview of the meta-stylesheet method

The workflow is meant to capture the provenance of step 2, on two levels of granularity: file-level and template-level. The file-level XSL transformation process references the input document, as well as the stylesheet(s) used. The process is controlled by the XSLT processor, and generates an output document. As with the Saxon trace, this method can only give the provenance information of the transformation process which created the output.xml.

Figure 4: Provenance at the file level

Figure 5: Sample file-level provenance documentation (provenance.rdf)

<!-- Provenance for the transformation of file:/C:/Users/Ashley/Desktop/global_001/input.xml 
using stylesheetC.xsl: -->
<xslt:Stylesheet rdf:about="stylesheetC.xsl">
    <xslt:version>1.0</xslt:version>
</xslt:Stylesheet>
<xslt:Processor rdf:ID="proc01">
    <xslt:vendor rdf:resource="http://www.saxonica.com/"/>
    <xslt:productName>SAXON</xslt:productName>
    <xslt:productVersion>PE 9.3.0.5</xslt:productVersion>
</xslt:Processor>
<xslt:Binding rdf:ID="alpha">
    <xslt:value>Y</xslt:value>
</xslt:Binding>
<xslt:Transformation rdf:ID="overall">
    <xslt:source rdf:resource="file:/C:/Users/Ashley/Desktop/global_001/input.xml"/>
    <xslt:stylesheet rdf:resource="stylesheetC.xsl"/>
    <xslt:processor rdf:resource="#proc01"/>
    <xslt:binding rdf:resource="#alpha"/>
</xslt:Transformation>

Like the overall transformation process, template-level provenance heavily uses the XSLT module for OPMV. Here, each xslt:Transformation points to an xslt:Template artifact, which could be of either subtype xslt:MatchedTemplate or xslt:NamedTemplate. The edge between the two is xslt:used. If the template firing was triggered by xsl:apply-templates, then it also contains a reference to the source node to which the template was matched. Any template, and thus any transformation, might contain parameters or variables, and thus, bindings. Unlike stylesheet bindings, a template parameter of the same name - but different rdf:ID! - can carry a different value every time the template is run.

Figure 6: Provenance at the template level

Figure 7: Sample template-level provenance documentation (provenance.rdf)

<!-- Template-level provenance: -->
<xslt:Template rdf:about="stylesheetC.xsl#art_t1">
    <rdfs:label>mode='#default', match='/', name=''</rdfs:label>
    <rdfs:comment>&lt;xsl:template match='/'&gt;
    &lt;html&gt;
        &lt;head&gt;
            &lt;meta http-equiv='Content-Type' content='text/html; charset=UTF-8'&gt;&lt;/meta&gt;
            &lt;title&gt;Provenance&lt;/title&gt;
        &lt;/head&gt;
        &lt;xsl:apply-templates&gt;&lt;/xsl:apply-templates&gt;
    &lt;/html&gt;
&lt;/xsl:template&gt;</rdfs:comment>
    <opmv:wasEncodedBy rdf:resource="stylesheetC.xsl"/>
</xslt:Template>
<xslt:Template rdf:about="stylesheetC.xsl#art_t2">
    <rdfs:label>mode='#default', match='compute', name=''</rdfs:label>
    <rdfs:comment>&lt;xsl:template match='compute'&gt;
    &lt;body&gt;
        &lt;xsl:apply-templates&gt;&lt;/xsl:apply-templates&gt;
    &lt;/body&gt;
&lt;/xsl:template&gt;</rdfs:comment>
    <opmv:wasEncodedBy rdf:resource="stylesheetC.xsl"/>
</xslt:Template>
<xslt:Transformation rdf:ID="pr_d1-1">
    <rdfs:label>Template art_t1 applied</rdfs:label>
    <xslt:source rdf:resource="file:/C:/Users/Ashley/Desktop/global_001/input.xml#"/>
    <xslt:used>
        <xslt:MatchedTemplate rdf:about="stylesheetC.xsl#art_t1"/>
    </xslt:used>
    <xslt:processor rdf:resource="#proc01"/>
    <opmv:wasTriggeredBy rdf:resource="#overall"/>
</xslt:Transformation>
<xslt:Transformation rdf:ID="pr_d1e3-2">
    <rdfs:label xmlns="">Template art_t2 applied</rdfs:label>
    <xslt:source
        rdf:resource="file:/C:/Users/Ashley/Desktop/global_001/input.xml#/test[1]/compute[1]"/>
    <xslt:used>
        <xslt:MatchedTemplate rdf:about="stylesheetC.xsl#art_t2"/>
    </xslt:used>
    <xslt:processor rdf:resource="#proc01"/>
    <opmv:wasTriggeredBy rdf:resource="#pr_d1-1"/>
</xslt:Transformation>

<!-- Provenance for the transformation of file:/C:/Users/Ashley/Desktop/global_001/input.xml 
using stylesheetC.xsl: -->

<xsl:comment> Provenance for the transformation of <xsl:value-of select="base-uri()"/> 
using stylesheetC.xsl: </xsl:comment>

<xsl:element name="xsl:comment">
    <xsl:text> Provenance for the transformation of </xsl:text>
    <xsl:element name="xsl:value-of">
        <xsl:attribute name="select">base-uri()</xsl:attribute>
    </xsl:element>
    <xsl:text> using </xsl:text>
    <xsl:value-of select="$regularStylesheet"/>
    <xsl:text>: </xsl:text>
</xsl:element>

<!-- Set up the xslt:Transformation for $regularStylesheet and its input. -->
<xslt:Transformation rdf:ID="overall">
    <xslt:source>
        <xsl:element name="xsl:attribute">
            <xsl:attribute name="name">rdf:resource</xsl:attribute>
            <xsl:element name="xsl:value-of">
                <xsl:attribute name="select">base-uri()</xsl:attribute>
            </xsl:element>
        </xsl:element>
    </xslt:source>
    <xslt:stylesheet>
        <xsl:attribute name="rdf:resource">
            <xsl:value-of select="$regularStylesheet"/>
        </xsl:attribute>
    </xslt:stylesheet>
    <xslt:processor>
        <xsl:attribute name="rdf:resource">
            <xsl:text>#proc01</xsl:text>
        </xsl:attribute>
    </xslt:processor>
    <xsl:for-each select="/(xsl:transform | xsl:stylesheet)/xsl:param">
        <xslt:binding>
            <xsl:attribute name="rdf:resource">
                <xsl:text>#</xsl:text>
                <xsl:value-of select="@name"/>
            </xsl:attribute>
        </xslt:binding>
    </xsl:for-each>
</xslt:Transformation>

<xsl:template match="xsl:call-template">
    <xsl:copy>
        <xsl:copy-of select="@*"/>
        <xsl:element name="xsl:with-param">
            <xsl:attribute name="name">provTemplate</xsl:attribute>
            <xsl:attribute name="tunnel">yes</xsl:attribute>
            <xsl:text>called</xsl:text>
        </xsl:element>
        <xsl:element name="xsl:with-param">
            <xsl:attribute name="name">provTrigger</xsl:attribute>
            <xsl:attribute name="tunnel">yes</xsl:attribute>
            <xsl:element name="xsl:value-of">
                <xsl:element name="xsl:text">#pr_</xsl:element>
                <xsl:element name="xsl:value-of">
                    <xsl:attribute name="select">generate-id()</xsl:attribute>
                </xsl:element>
                <xsl:element name="xsl:text">-</xsl:element>
                <xsl:number count="xsl:template" level="any"/>
            </xsl:element>
        </xsl:element>
        <xsl:apply-templates/>
    </xsl:copy>
</xsl:template>

Future work

The meta-stylesheet has been successfully created, and it can provide file- and template-level provenance documentation for XSL transformations, as shown in the examples above. Still, there are a number of questions still left to explore regarding the meta-stylesheet method and XSLT provenance documentation. For example, how much provenance collection is too much? Further work can be done to include finer levels of granularity, but it probably isn't necessary to document every XSLT instruction. What about coarser granularity? If XSLTs are used in a workflow, what kinds of provenance documentation can be generated, and what should it look like?

Unfortunately, the meta-stylesheet method does not entirely fulfill the assumptions listed previously, especially in ease of use. No matter what version of XSLT is used by stylesheet A, both the meta-stylesheet and stylesheet B currently require the use of an XSLT 2.0 processor. This certainly limits the number of processors able to make use of this method without fuss. Further, the meta-stylesheet has only undergone testing using the Saxon HE and PE processors shipped with oXygen. More testing is needed to ensure that the approach works in broader contexts, with other tools and XSLT 2.0 processors.

But the biggest problem with this approach is the meta-stylesheet's inability to say anything concrete about the output of stylesheet A. Neither the meta-stylesheet nor stylesheet B has knowledge of the actual contents of output.xml, although a good estimation can probably be made by modifying the structure of stylesheet B. It is unclear whether this is a beneficial side-effect (as in workflows where intermediate outputs may not be available) or something that should be fixed.

Besides attempting to solve these questions, I continue to test the meta-stylesheet against a greater number of input stylesheets, and to include other types of provenance information, such as the template descriptions given by the oXygen Editor. Even at this date, this project shows that an impressive amount of provenance information can be generated with just XSLT.

Acknowledgements

Many, many thanks to Wendell Piez for coming up with the idea for a meta-stylesheet, as well as providing guidance and technical help along the way. Thanks also to Allen Renear, Megan Senseney, and my colleagues at CIRSS for their advice and unflagging support.

This project was supported by DCEP-H, an initiative to extend the Data Curation Education Program to the humanities. Funded by IMLS Grant RE-05-08-0062-08, DCEP-H was based at the Center for Informatics Research in Science and Scholarship at the University of Illinois at Urbana-Champaign.