I am developing an application that needs to read a subset of a large XML file and transform it on-the-fly to generate a dynamic page. This is all dependent on a user selection. As far as I can tell, the best way to support this functionality is with transformNode(). Please let me know if there are alternatives or workarounds.

Sorry, this is probably more appropriate for the DOM folks...

If transformNode() is not part of the W3C specs, it's unlikely to be supported...

This is a valid RFE, confirming. We should and will support this somehow, but I'm not really sure if I like IEs syntax. The advantage would be compability with IE though...

My concerns are: 1) The functionality is there 2) All specs are followed Since this is not yet part of any DOM spec, by all means, innovate! I'd rather have the Mozilla idiom set the standard.

I'm not sure the functionality is there yet, but I don't know all the specifics of the IE method. You are aware that we have transformDocument?

Let's get this straight. The functionality isn't there. Generating the page on the fly looks like you want to use js to display the result. Nogo, this is bug 56087. Axel

My understanding of transformDocument is that it transforms from a document to a document. But does this allow one to transform from a document fragment to a document fragment? If transformDocument handles fragments, I agree, this is bug 56087. Otherwise, I'm happy to call it an RFE.

Could you set the URL to a documentation of transformNode()? That way poor folks like me who can't run ms products can evaluate this Thanx Axel

Quoting from the doc: strValue = oXMLDOMNode.transformNode(objStylesheet); Yes, STRING. And then they use innerHTML to display this. hihihi. oh sorry. Peter, you're module owner, I leave the wontfix up to you. Axel

Beat me to the URL by a minute or two... I didn't realize there was a field or I'd have done it from the start. Clearly, String and innerHTML are a bad idea. I agree that the syntax stinks. If it returns a fragment of the resultant DOM tree, it will be closer to what I need anyway.

Updating summary. Don't copy IE, improve upon it.

Not sure if this should be dupped of or just depend on bug 46633

stripping bugs apart. This is the bug about a [script] interface to XSLT. We're not intending to kill nsIDocumentTransformer, but we never encouraged the use of it in scripting either. This bug is supposed to give us something we wanna encourage people to use. This bug is including a fix to bug 70369, argh, deps don't cut it.

************************************************************************* *** Note for drivers: *** *** If someone comes up with a fix for this soon, please do not *** wave it off to post-1.0 if at all possible. This is _the_ bug *** people are demanding on the newsgroups, check e.g. n.p.m.xml *** and n.p.m.layout.xslt . And IE has this. *************************************************************************

Note that the ability to output a string containing HTML allows them to use this server side where the HTML is written to the output document. In addition it possibly allwos their downlevel browsers to call their ActiveX impl and have it return a string of HTML and then allow the downlevel browser to simply set the innerHTML. Both approches are useful to them and you can expect to seem them in the wild. Note that they have another method which does result in a Node output: oXMLDOMNode.transformNodeToObject(stylesheet, outputObject); http://msdn.microsoft.com/library/en-us/xmlsdk30/htm/xmmthtransformnodetoobject.asp Without this functionality, however it is exposed, consider how an author would implement it on their own.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

Here are the two interfaces. I don't think the interfaces should go to extensions/transformiix, and they're not DOM so they ended up in content/xsl/public. Note: I won't have time to implement this.

setParameter should throw an exception if - init hasn't been called sucessfully - or the given expanded name is not a parameter of the given stylesheet. We must not pass in data that is not tunneled by a global paramater (top level xsl:parameter instruction)

This bug seems to be dead. I just wanted to say that I really care about this feature - it's something crucial if I want to use XSLT in my applications, and run them in Mozilla.

the design for bug 90157 and bug 130161 need to worship each other. Esp. one needs the creation of the document during the transform, the other needs to work on an existing document.

<sicking> i really think we should return a node instead of a DocFragment <sicking> so that if you specify a null outputdoc we create the doc and return that I don't like the idea of having a return value of separate meanings. If we want a method to return a new document, equivalent to what (will) happen(s) on PI in content, then we should add another method. IMHO.

I have developed many web applications that create content dynamically from XML documents stored in memory through Javascript on IE. I would love to do the same with Mozilla. But with Mozilla, I could create much better applications thanks to XUL. I have also written a simple Java applet that has a transfromNode method that I can call from Javascript in Mozilla. I will attach an example xsl file to demonstrate its usefulness.

This file is used to take an xml document which represents a "timeslip" (obtained through XMLHttpRequest from a SOAP server) and transform it into a html form. The output is equivalent for msxml (IE browser) and Java + Mozilla. Here is an example timeslip: <timeslip xmlns:netpos="http://www.netpos.com" timeslip_id="1" store_id="2001" start_time="1032209986" end_time="" modified="1032209986" terminal_number="1" in_manager_id="" money_in="" out_manager_id="" money_out="" employee_id="" job_id="" cash_tips="" /> <worker xmlns:netpos="http://www.netpos.com" type="terminal" timeslip_id="1" ><terminal enable_pht="false" mode="crmode" name="front" number="1" store_number="1"/></worker>

fixed with the branch-landing. We should make an announcement in the newsgroups what the new interfaces look like. And fix the project page

mass verifying