Thanks Joseph,
As a "dirty" workaround I'm transforming a document and copying all the
root branches to a new document which already has docType set.
That will slow down the transformation, but at least it works. (I hope
it's faster than transforming into stream and creating DOM from stream)
DocumentType documentType = impl.createDocumentType(
outDocument.getDocumentElement().getNodeName(),
prop.getProperty("doctype-public"),
prop.getProperty("doctype-system"));
Document newDoc = impl.createDocument(null,
outDocument.getDocumentElement().getNodeName(), documentType);
// copy XML branches of the root element.
NodeList nodeList =
transformedDocument.getDocumentElement().getChildNodes();
for (int item = 0; nodeList.getLength() > item; item++) {
Node node = nodeList.item(item);
newDoc.getDocumentElement().appendChild(newDoc.importNode(node, true));
}
If anybody has a suggestion - please let me know.
- Vlad
To: "Vlad.Epshtein" <[EMAIL PROTECTED]>
cc: xalan-j-users <[EMAIL PROTECTED]>
Subject: Re: DocumentType information lost while transforming DOM to DOM
>The only problem is that i'm doing DOM to DOM transformation
There's a sequencing problem here: the DOM APIs say that the Doctype must
have been created first, and used in the Document's creation; it can't be
added later. And the DOM APIs say createDocument also creates the root
element, and that the root element may not be removed.
These behaviors may change in future versions of the DOM spec; DOM Level 3
is reconsidering some of them. But for now I'm afraid you're stuck, as far
as standard APIs are concerned.
Specific DOM implementations may offer nonstandard APIs which would get
you
closer to what you need. Of course that means giving up portability.
Can we do anything about this? Maybe, if we extend our own APIs.
The right solution would probably be for the XSLT processor to take over
creation of the Document node. The best approach I can see would be to
extend TrAX, adding a variant of DOMResult which accepts a
DOMImplementation object rather than a Document. When passed this result
object, the tree builder would create the doc only after it knows what the
root element will be.
If we're going to add this, I'd really like to see it accepted into TrAX
rather than being supported only by Xalan. That's more difficult
politically, but I think a decent argument can be made for it.