365213 - XSLT: Processing instructions of generated document are ignored (i.e., there no pipelining of transformation)

Status: RESOLVED WONTFIX

(Core :: XSLT, defect, P5)

Description

[Ruvim Pinka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

It is denoted the following behavior:

Source xml document, fragment:
<?xml version="1.0" encoding="ascii" ?>
<?xml-stylesheet type="text/xsl" href="struct-pre.xsl"?>
<root>...


The struct-pre.xsl document, fragment:

<xsl:output omit-xml-declaration="no" />
<xsl:template match="/" >
  <xsl:processing-instruction name="xml-stylesheet">
    <xsl:text>type="text/xsl" href="struct-second.xsl"</xsl:text>
  </xsl:processing-instruction>
  <xsl:apply-templates />
</xsl:template>

Now, the output xml document will get xml-stylesheet instruction and may have
next (likeness recursive) transformation with struct-second.xsl.

Reproducible: Always

Steps to Reproduce:
The "test-xsl-pipeling.xml" test case will be attached, please, see above.

The following command-line transformation is equivalent:
msxsl test-xsl-pipeling.xml test-xsl-pipeling.xml >stage1.xml
msxsl stage1.xml stage1.xml >stage2.html
Actual Results:  
test passed 
First

Last

Expected Results:  
First
test passed
Last

Of course we can do such pipeline transformation on server side, or at client side by using JavaScript. But sometimes such pipelining on client without JavaScript is more elegant and traffic less. Also it allow to make workaround of "documents order problem" (see Bug 323547).

This report was split out from  Bug 230214

Comment 1

[Ruvim Pinka]

Attachment: Test case of XSLT pipelining

All required XML-documents in one file :)

Comment 2

[Peter Van der Beken [:peterv]]

I vote for WONTFIX (and bug 323547 should be fixed by remembering load order). Sicking?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think we should WONTFIX this, but I'm not planning on working on this myself. If someone comes up with a non-intrusive patch I'd be for taking it though.

Now that we support exslt:node-set you can actually do this fairly easy in a single stylesheet. Simply do something like:

<xsl:styleshet ...>
<xsl:include href="stylesheet1.xsl">
<xsl:include href="stylesheet2.xsl">
<xsl:include href="stylesheet3.xsl">
<xsl:include href="stylesheetN.xsl">
<xsl:template match="/">
  <xsl:variable name="res1">
    <xsl:apply-templates select="." mode="pass1"/>
  </xsl:variable>
  <xsl:variable name="res2">
    <xsl:apply-templates select="exslt:node-set(res1)" mode="pass2"/>
  </xsl:variable>
  <xsl:variable name="res3">
    <xsl:apply-templates select="exslt:node-set(res2)" mode="pass3"/>
  </xsl:variable>
  ...
  <xsl:apply-templates select="exslt:node-set(resN)" mode="passFinal"/>
</xsl:template>
</xsl:stylesheet>

The only thing you have to do differently is that in the various stylesheets you have to give all templates a special mode and remember to always use that mode whenever you use <xsl:apply-templates>

Comment 4

[Ruvim Pinka]

Just for reference: xml-stylesheet PI of the generated document is applied in case of type="text/css" — see also Bug 186835
So, not any but only "xsl" xml-stylesheet PI is ignored despite of the current bug title (maybe we should edit this title).

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Given the low amount of XSLT usage on the web, I think it's pretty safe to say that we won't implement this.