RE: RE: [xsl] Problems with Oracle XSL processor

Subject: RE: RE: [xsl] Problems with Oracle XSL processor
From: cknell@xxxxxxxxxx
Date: Thu, 02 Jan 2003 12:59:02 -0500
>It might be useful if you told us what the alleged problem is. There >are
>cases where different processors can legitimately produce different
>output and still be conformant to the spec.
>
>If it really is a non-conformance, there is little anyone on this >list
>can do to help: it's an issue between you and your software supplier.
>
>Michael Kay

Someone who has a good deal of experience with the quirks of the Oracle transformer might be able to help, but as it turns out, I have solved the problem. If anyone is interested in the details, read below. A precis of the problem is that my stylesheet had one level of indirection too many for the Oracle transformer.
*************************************************
I'm working on a sort of "Cocoon-for-PL/SQL" project. That is to say, I have an XML map of an application which controls the generation and transformation of XML via XSLT with eventual serialization to either the Oracle database or a browser. The stylesheet I had written for one step of the process worked fine when I tested it with Xalan-J, so I thought nothing of including it in the application.

The stylesheet produces an intermediate XML file which is a more-highly structured format than the input document. The input document has a structure like this:
<root>
    <row sort-order="1" measure-id="technical">
    <row-head>Technical</row-head>
    <col period="20011" value="Green"/>
    <col period="20012" value="Green"/>
    <col period="20013" value="Green"/>
    <col period="20014" value="Green"/>
    <col period="20021" value="Green"/>
    <col period="20022" value="Amber">Speed up.</col>
  </row>
.. (sixteen more "row" elements appear here)
</root>

The output is structured so that groups of three "col" elements with consecutive "period" attributes are grouped into "table" elements like this:
<data-tables>
  <table id="page-1">
.. (some HTML table formatting elements appear here)
    <tr>
      <td class="row-head">Technical</td>
      <td id="technical-20014" class="green-cell">Green</td>
      <td id="technical-20021" class="green-cell">Green</td>
      <td id="technical-20022" class="amber-cell">Amber</td>
      </tr>
.. (sixteen more "tr" elments appear here)
  </table>
  <table id="page-4">
  ...(seventeen "tr" elements appear here)
  </table>
</data-tables>

The problem was that using the Oracle transformer, the <tr> elements containing the data (as opposed to the table column header stuff) were not being emitted for the element with an id of "page-1" while the element with the id of "page-4" contained all the expected <tr> elements. The other three transformers worked as expected, all <tr> elements were present.

I made a stripped-down version of the stylesheet to send along. I omitted anything I thought was not germane to the problem. Imagine my surprise when the rows which had been missing from the output using the Oracle transformer appeared when I tried it again.

I then carefully examined my "lite" stylesheet to compare it to the original version. In making the lite version, I replaced a <xsl:for-each> section with a template and a <xsl:apply-templates> section. This immediately broke because the code transferred to the new template depended on variables created in the section from which it had been taken but were now out of scope.

My first try at fixing this involved passing the values of the variables as parameters to the new <xsl:apply-templates> element. This looked bad. I realized that I was adding to complexity by declaring variables and then assigning their values to parameters. I decided instead to omit creating the variables and assign the values directly to the parameters as I passed them to the <xsl:apply-templates> element. This was the only place I used them, so this was practical.

This second approach worked I got the formerly-missing output and the code was simpler. Stunned by the success, I went back to my original stylesheet and made the same change to the "heavy" version. That worked too! The Oracle processor (using the simpler stylesheet) now output all the elements I was expecting and which had been output by MSXML, Xalan-J, and Instant Saxon with the older version of the stylesheet.

My immediate problem is solved, but I still think that a conformant transformer should work with any conformant stylesheet. This kind of minimal conformity is like the smart-alec kid who promises something only betray the promise saying, "I had my fingers crossed!"
----------------------------
Charles Knell
cknell@xxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread