Proposal on how XSLT processor creates result documents

NEW
Assigned to

Status

()

Core
XSLT
--
enhancement
13 years ago
9 years ago

People

(Reporter: Simo Melenius, Assigned: peterv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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:
(Reporter)

Comment 1

13 years ago
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.
(Reporter)

Comment 3

13 years ago
Created attachment 174033 [details] [diff] [review]
Changes how createResultDocument() instantiates the document
(Reporter)

Updated

13 years ago
Attachment #173367 - Attachment is obsolete: true
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...
Attachment #174033 - Flags: superreview?(peterv)
Attachment #174033 - Flags: review?(bugmail)
What I don't understand is how this helps create custom documents?
CreateDocument on nsDOMImplementation always creates xml documents.
(Assignee)

Comment 6

13 years ago
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.
Attachment #174033 - Flags: superreview?(peterv)
Attachment #174033 - Flags: review?(bugmail)
Attachment #174033 - Flags: review-
QA Contact: keith → xslt
You need to log in before you can comment on or make changes to this bug.