XSLT mapping algorithm

Question

I have a particular problem I'm not sure how to approach. Here at the office there is this large unwieldy XSLT we have for adapting one type of XML to another. The problem is that it's not very consistently written and very difficult to follow. In the ancient creation of this stylesheet, it seems it was forgotten exactly what it does.

Is there a way to easily map out in a human-readable format exactly what the giant XSLT does? i.e. Every possible input -> Every possible output. We can't create an all-encompassing input document, since the adapter has different behavior for different input (We estimate it would take 100+ input documents to cover every possible output)

Any suggestion would be greatly welcome.

Answer 1

Break it up -- move the xsl execution statements to xsl templates inside the document. By doing this, you'll work down to a more reasonable understanding of the document from the top down.

And if it's so incredibly gigantic as to prevent you from understanding it, this sounds like you have a re-factoring decision ahead of you: is this document so important that we need to know what it does (and understand how it works -- thus requiring some re-work), or can we live with it as-is?

Answer 2

Do you understand your input documents?

If Yes skip next sentence else No:-

Then you can't test any resulting re-factor of XSLT hence you need to make the answer to this question, Yes.

Do you understand your output documents?

If Yes skip next sentence else No:-

Then you can't test any resulting re-factor of the XSLT hence you need to make the answer to this quesion, Yes.

Now that the answers to both questions is Yes, ditch the XSLT and build something you can understand. You know what the input is and you know what output you want, classic von-newman (do they still teach that these days?).

Answer 3

Generally this is impossible task -- for any programming language!

This follows from the undecidability of the halting problem.

Therefore, you may put enormous effort in trying to do something that is proven to be impossible.

My recommendation is to write your own solution, following best programming practices, using unit tests and if possible correctness proofs. XSLT as a functional language is better suited for proving correctness.

Answer 4

This is not going to help you in all probability. But I'll share my experience.

I was treating myself to XSLT only about yesterday when I had the same problem trying to figure out what the XSLT specification was saying w.r.t. parsing. What I did, to help myself, was add a couple of functions (xsl:template's, to be pedantic) to the original XSL. Next, I ran it through the browser, and voila, I had a clear picture of the DFS.

I created the following:

<xsl:template name="print">
<xsl:param name="message"/>
<xsl:param name="elem"/>
<div class="ArticleBody">
  <br/>
  <xsl:value-of select="$message"/>: <xsl:value-of select="$elem"/> ... <br/>
</div>

The print template is the worker and the prologue and epilogue simply calls print with custom strings.

And I put changes the original XSL file from:

<xsl:template match="db:para">
 <xsl:apply-templates/>
</xsl:template>

to:

<xsl:template match="db:para">
 <xsl:call-template name="prologue">
   <xsl:with-param name="item" select="'para'"/>
 </xsl:call-template>
 <xsl:apply-templates/>
 <xsl:call-template name="epilogue">
  <xsl:with-param name="item" select="'para'"/>
 </xsl:call-template>

I'd now get an output when every node was processed:

start-processing: article ... 

and when it completed

end-processing: article ...

I threw in a bit of CSS as well (when processing the root node) just so things look good. And that kind of made my day :)