XSLT interface to mozilla/content needs some love




18 years ago
15 years ago


(Reporter: Axel Hecht, Assigned: peterv)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: reopened for mozilla1.0 interface discussion)



18 years ago
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?


Comment 1

18 years ago
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?


Comment 2

18 years ago
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

18 years ago
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).


Comment 4

18 years ago
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 
(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

18 years ago
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.
Assignee: nisheeth → peter.vanderbeken

Comment 6

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

Severity: normal → enhancement
Last Resolved: 18 years ago
OS: Solaris → All
Hardware: Sun → All
Resolution: --- → LATER
Target Milestone: --- → Future

Comment 7

17 years ago
reopening, mozilla1.0 should have a sane interface.
Let's keep this bug on the interface to be used by content, ie. 
Severity: enhancement → major
Resolution: LATER → ---
Whiteboard: reopened for mozilla1.0 interface discussion
Target Milestone: Future → mozilla1.0

Comment 8

17 years ago
die pandora, die
Assignee: peter.vanderbeken → peterv

Comment 9

17 years ago
adding mozilla1.0 keyword. This is a real 1.0 issue, IMHO.
Keywords: mozilla1.0

Comment 10

16 years ago
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.
No longer blocks: 70369, 90157
Severity: major → normal
Keywords: mozilla1.0
Summary: XSLT interface needs some love → XSLT interface to mozilla/content needs some love
Target Milestone: mozilla1.0 → Future


16 years ago
Depends on: 155578
fixed with the branch-landing
fixed by branch landing
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 13

15 years ago
mass verifying
You need to log in before you can comment on or make changes to this bug.