212636 - JS XSLT interface does not allow returning of result tree from method

Status: RESOLVED INVALID

(Core :: XSLT, defect)

Description

[Manos Batsis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

The current nsIXSLTProcessor implementation cripples some usability of XSLT
functionality in JS when compared to the nsIXMLProcessorObsolete. JavaScript
only allows function parameters to be passed by value, not by refference. Using
nsIXMLProcessorObsolete one could isolate transformation logic by enclosing it
in a function signature as follows:

function transformDocument(sourceDoc, xsltDoc, resultDoc)
{
   // assume nsIXMLProcessorObsolete is available
   var xsltProcessor = new XSLTProcessor();
   xsltProcessor.transformDocument(sourceDoc, xsltDoc, resultDoc, null);
   // return the *modified* result. 
   return resultDoc;
}

This works fine. However, the only way to do this using the new nsIXMLProcessor
would be something like:


function transformDocument(sourceDoc, xsltDoc, resultDoc)
{
   // assume nsIXMLProcessor is available
   var xsltProcessor = new XSLTProcessor();
   xsltProcessor.importStylesheet(xsltDoc);
   resultDoc = xsltProcessor.transformToDocument(sourceDoc);
   // return the *modified* result. 
   return resultDoc;
}

But the modifications to resultDoc are not visible outside the method now due to
the nature of the JavaScript language. So, what I'm asking for is for
nsIXMLProcessor to change, restoring the JavaScript centric usability that was
available in the obsolete interface.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Axel Hecht]

One of the essential features of XSLT is that the type of the output document is
not known. Thus modifications of an existing document can not be conformant to
both the XSLT spec and the HTML spec.

Transforming into an existing document is really brittle and the expected result
is vague. Whether you want to replace parts of an existing document or add content
by XSLT is unknown to the implementation, though both are valid use cases. Thus
we introduced the transformToFragment, which gives you the level of control you
deserve while still supporting both XML and HTML output methods as good as 
possible.

It's not a bug, it's a feature. Really.