281071 - Proposal on how XSLT processor creates result documents

Status: NEW

(Core :: XSLT, enhancement)

Description

[Simo Melenius]

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:

Comment 1

[Simo Melenius]

Attachment: Draft patch to make transformiix create output documents via DOMImplementation

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Simo Melenius]

Attachment: Changes how createResultDocument() instantiates the document

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

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

What I don't understand is how this helps create custom documents?
CreateDocument on nsDOMImplementation always creates xml documents.

Comment 6

[Peter Van der Beken [:peterv]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

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

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 9

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

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.