46633 - XSLT interface to mozilla/content needs some love

Status: VERIFIED FIXED

(Core :: XSLT, defect, P3)

Description

[Axel Hecht]

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

Comment 1

[Axel Hecht]

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

Comment 2

[Jus]

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?

Comment 3

[Axel Hecht]

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

Comment 4

[Jus]

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).

Comment 5

[Nisheeth Ranjan]

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.

Comment 6

[Axel Hecht]

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

Axel

Comment 7

[Axel Hecht]

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

Comment 8

[Axel Hecht]

die pandora, die

Comment 9

[Axel Hecht]

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

Comment 10

[Axel Hecht]

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.

Comment 11

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

fixed with the branch-landing

Comment 12

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

fixed by branch landing

Comment 13

[Axel Hecht]

mass verifying