What's wrong? - the interface relies on DOM trees, but we need the document root for XSLT - we can only apply one transformation, but multiple processing instructions are legal, and covered in the standard - the transformed document can't request another transformation What'd be cool? There should remain a way to call XSLT from js. But do we need to feed it documents or URLs? I see more use of applying XSLT to dynamic data, than to dynamically modify the stylesheet. So I would like a way to give the DOM document for the XML, but not necessarily the DOM document for the XSL, to me a URL would do. XSL stylesheets are no single document anyway. Parsing of the XML document doesn't need any extra love, but some work on the XSL document can be done at parsing time, as parsing the xpath expressions and loading <xsl:include>s and <xsl:import>s Any ideas? Who should be on the CCs? Axel

Another thing I forgot: To correctly parse XPath expression, we need to map prefixes to namespaces, propably just the IDs. I didn't see any method for this in nsXMLDocument, just in nsXMLContentSink. Is that right? Axel

Sounds good. A few questions: 1) Multiple processing instructions, as I read the spec, are handled by creating a parent stylesheet that has the multiple instructions as imports so as to effectily merge them, is this your understanding? 2) I didnt come across the chaining of transformations, other than as a throw away line in the spec saying it could be done. Any ideas how we would inform the XSLT engine? Could we assume this could be carried out from JS in stages for simplicity, and let XSLT deal only with a single transformation at a time?

Hi Jus, the triggering for multiple transforms is to have a processing instruction in the transformed document for another tranformation. The way I'd like to see us coping this, is to feed the output from the XSLT process to a nsXMLContentSink, which would find out about it, and trigger another engine and transformation. I don't know enough about the layout structure, whether we even could go for a more basic content sink, so we could create the right sink for text, xml or html. Is this fiction? Concerning the single transform with multiple stylesheets, we could create a mockup stylesheet, including the real ones, but this would, taking the current design, delay the loading and parsing of the stylesheets to transforming time. Bad Thing (TM). Axel

Axel, Not sure how far you or anyone else have gone with this, so Ill throw my 2c in. A few comments from nisheeth about now would be great. :) 1) nsXMLContentSink::Observe() knows the completion of a transformation so as a starting point if it could be taught to handle new PI tranforms in the output and trigger a new transform that may give us XSLT chaining. This is set via TransformMediator. (But if we let JS mess with the observer what would we do then?). Then again we could do it all from the Transformation entry point, before/during/after letting the observer(s) know. 2) Ability to add an error observer to transformation from TransformMediator land would be handy. 3) Multiple transform observers? 4) Additions to nsIXMLDocument to expose methods for setting the XSL stylesheet (Url?) and Observer(s). Or maybe just enhance the TransformMediator for Document parameters and URL parameters for the calls its got, and expose the TransformMediator to JS (For all I know its already done).

Peter has changed the interface so that it uses DOM documents rather than DOM trees. Re-assigning to him so that he can close this out. For other things, we should probably file separate, more specific bugs.

Moving this bug down the road. It most definitly is not new, but later. Axel

reopening, mozilla1.0 should have a sane interface. Let's keep this bug on the interface to be used by content, ie. nsIDocumentTransformer

die pandora, die

adding mozilla1.0 keyword. This is a real 1.0 issue, IMHO.

stripping out our bugs. This one is for the noscript part used by content. We're not gonna do anything serious to content for 1.0, so this is future.

fixed with the branch-landing

fixed by branch landing

mass verifying