Saxon extracting extraneous lines

Question

I am trying to report on a Spring configuration: Of course the XML has a lot of depth and the important pieces are pretty deep. The interesting flow can be summarized as follows with multiple property elements omitted.

bean
-property
--list
---bean
----property name="phaseName"
----property name="pluginID
----property name="fileSpecifications"
-----set
-------bean
--------property name="dataStoreName" value="courses"
--------property name="columnNames"
---------list
----------value
----------value

In the xsl, I get to the second bean level and extract the pluginID and then find the "fileSpecifications" where I get the "dataStoreName". For no reason that I can see, Saxon also extracts the list of values with a lot of empty line and extra tabs.

The extra text is from a property called "columnNames" which is not referenced in the XSL file anywhere. In debugging by adding xsl:message statements, I have not been able to determine which template is doing this extraction.

In case that this is hard to read in the mailing list, I have created a blog entry http://blog.artifact-software.com/tech/?p=296 describing the files that can be downloaded and executed. I can provide more sample phase files if required.

There is a higher level bit of processing in the xsl that reads a master configuration and finds all of the files that are imported. It matches the file with the phase so that the phases can be reported in the same sequence that the phases will be processed. The xsl builds the list and then processes each file in turn.

Even if I remove the code that extracts the dataStoreName value attribute, I still get the columnNames list of values.

Is this a know bug or have I done something silly?

Extract from the output

<tr>
   <td class="header">Bean Name</td>
   <td class="header">Plugin Name</td>
   <td class="header">DataStore Name</td>
 </tr>

 <tr>
    <td class="id">CourseWriterOutputting a row</td>    
    <td class="pluginId">Plugin ID:CourseFileWriter<br>Usage Description</td>
    <td class="dataStoreName"></td>
    <td>
                 courses

                   TITLE
                   PMI_REPORTING_NUMBER
                   IIBA_REPORTING_NUMBER
                   DEFAULT_CURRENCY
                   PRICE
                   OFFERING_TEMPLATE_NO
                   ABSTRACT

The extract of the xsl is Outputting a table /xsl:variable>

<caption><xsl:value-of select="$phaseName" />
  from <xsl:value-of  select="$resourceName" /></caption>
<tr>
<td class="header">Bean Name</td><td class="header">Plugin Name</td>
<td class="header">DataStore Name</td>
</tr>
 <xsl:apply-templates select="document($fileName)/sb:beans/sb:bean" />
 <xsl:apply-templates
  select="document($fileName)/sb:beans/sb:bean/sb:property[@name='plugins']/sb:list" mode="plug-in"/>

</table>
</xsl:template>

Instead of "extracts", please show complete, reproducible examples of the code. In the case of XSLT questions, this means a complete XSLT stylesheet, a complete input XML document and the output you expect. Help: http://stackoverflow.com/help/mcve. — Mathias Müller, Feb 19 '16 at 07:41
Even when I follow the link in your post (something I don't normally do: SO discourages such links, because people will still be visiting this question 10 years from now), I can't see the XSLT code. Without seeing the XSLT code, I can't help you debug it. The most common reason for getting more output than you want is that it is produced by the built-in template rules, which fire when you have an apply-templates that selects a node for which there is no explicit template rule. — Michael Kay, Feb 19 '16 at 08:53

score 0 · Answer 1 · edited May 23 '17 at 12:31

It was suggested that it might be XSLT built-in templates and I found Why does XSLT output all text by default? which gave me hints about how to find the leaks.
This led to a test of a single input file version which enabled me to find the source of the leak.
I needed to tighten up the select on the inner apply templates so it only exposed the <property> that I wanted rather than all properties.
I will update the blog article with the revised source code.
I had no trouble following the links to the source in the original reference but your point about 10 years from now is very good.
I was reluctant to post several hundred lines of code and more lines of input but even without seeing the code, you identified the source of my grief.

Saxon extracting extraneous lines

1 Answers1