User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 Currently txMozillaXMLOutput::createResultDocument creates a hardcoded result nsXMLDocument for non-HTML output. This may not be what is wanted if there are other nsDocument-inheriting document types that implement semantics and content creation that differ from nsXMLDocument's. If the result document's type defaulted to the source document's type, it'd at least make fewer assumptions about the nature of the result document. This could be achieved by creating the result document through source document's DOMImplementation. That would allow the alien implementation to take over in how the document and subsequent elements are created. This was the case in DocZilla development where we provide our own SGML/XML content classes. I wrote a small patch that works for us here; if it's of a more general use for Mozilla.org community, feel free to adopt it or something similar. Reproducible: Always Steps to Reproduce:
Created attachment 173367 [details] [diff] [review] Draft patch to make transformiix create output documents via DOMImplementation
Comment on attachment 173367 [details] [diff] [review] Draft patch to make transformiix create output documents via DOMImplementation I'd suggest using "diff -up8" to create the patch... that will be much easier to review.
Created attachment 174033 [details] [diff] [review] Changes how createResultDocument() instantiates the document
Comment on attachment 174033 [details] [diff] [review] Changes how createResultDocument() instantiates the document Simo, see http://www.mozilla.org/hacking/life-cycle.html for things like how the review process works, etc... I'm going to request review from the right people for you on this one, just to make sure it doesn't get lost...
What I don't understand is how this helps create custom documents? CreateDocument on nsDOMImplementation always creates xml documents.
Note that I asked Simo to file a bug on this with his patch, because we need to discuss whether this is something we would take. I think reviews are a bit premature. IIRC Simo provides a custom DOMImplementation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
sicking, I think the idea is that a custom document class (inheriting from nsDocument) can override GetImplementation to return something that's not quite a nsDOMImplementation...
If you have to supply a 'custom' source document then I don't really like the approach. But it should be possibly to change nsDOMImplementation code to fit us better.
Comment on attachment 174033 [details] [diff] [review] Changes how createResultDocument() instantiates the document I don't really like this solution. First of all it requires clients to supply their own implementation of source document meaning that not just any document can be transformed. Second, how do you plan to subclass nsDocument and provide your own source-document-class? If you are patching the gkcontent library then couldn't you just patch transformiix too meaning that there is no need for this patch to go into cvs? In any case, this patch doesn't work since it inserts a documentelement and doctype into the document (or at least that is what the DOMImplementation *should* do according to spec). I'd rather see a document factory of some sort (which could be a DOMImplementation if you really want) being provided set as a property on the XSLTProcessor using the nsIXSLTProcessor interface.
You need to log in before you can comment on or make changes to this bug.