Beton, Richard wrote:
In anticipation of great things, I tried
public static final String W3C_SVG11_QNAME = "-//W3C//DTD SVG 1.1//EN";
public static final String W3C_SVG11_PUBLIC_ID = "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"; <http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd>;
...
SVGDOMImplementation impl = (SVGDOMImplementation) SVGDOMImplementation.getDOMImplementation();
DocumentType dt = impl.createDocumentType( W3C_SVG11_QNAME, W3C_SVG11_PUBLIC_ID, null );
SVGOMDocument document = new SVGOMDocument( dt, impl );
...
but alas this doesn't work because creating DocumentType instances is not supported by Batik. A DOMException is thrown. Is this a temporary shortcoming, i.e. are there plans to support DocumentType nodes in Batik's SVG DOM?
Why did you expect 'great things' from being able to set a DocumentType node? It is an over site in Batik, providing what you are looking for is trivial, it would be a bit more work to add support for recording entities when SAX parsing, but I'm not sure why you are so interested in this.
I had a look at the Xerces source code and there is there a complete DocumentType implementation. This raises a question (sorry if this is going over old ground) : why does Batik have its own generic DOM implementation when there is already a Xerces one?
Because we don't have any hard dependencies on Xerces. You can use what ever parser you want, Batik can use crimson, Xerces, I've even tried piccolo. It is likely that had we used the Xerces DOM implementation we would be tied to Xerces (unable to for example use the JDK parser in 1.4).
If Batik had built on the Xerces one, it would have saved effort and would have meant that such things as DocumentType implementations would be already present. The fact that the two implementations are different means I cannot use a Xerces DocumentType implementation with a Batik Document implementation.
Well, I wasn't part of the initial decision, but we have needed to _heavily_ customize the DOM to support CSS, various peculiarities of SVG (like use), so the real trade off would be the complexity of extending base classes we have no control over, vs reimplementation...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
