xsl-list
[Top] [All Lists]

RE: RE: Problems with Oracle XSL processor

2003-01-02 10:59:02
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(_at_)onebox(_dot_)com

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