So the answer to your question is, I don't know. The real question is how much would be broken if the code started to "trust" the code calling the ContentHandler? :)
I think I already identified one case where it wouldn't work properly (a 'raw' SVG file with no namespace decls or DTD specified). This is I think an important case.
If the code can be constructed such that it handles this case and still properly respect the ContentHandler interface (which admittedly it is currently not doing a good job of) then that would be great.
I suppose one option is to keep the code mostly the same except have it use start/endPrefixMapping to update the namespace hash it maintains rather than parsing the attributes it's self (then it can still 'stuff' the namespace has with a default namespace).
Part of the issue is that I really trust the guys who wrote this code to know the DOM so I am loath to muck with it too much. Any idea if SAX impls tend to 'mess up' start/endPrefixMapping?
------
K. Ari Krupnikov wrote:
[EMAIL PROTECTED] (K. Ari Krupnikov) writes:
Thomas DeWeese <[EMAIL PROTECTED]> writes:
You would have to rewrite parts of it (I don't think it would be hard, in fact if you were willing to trust the URI passed into start element it would simplify things a fair amount).
I could do that. Although I'm tempted to ask if the maintainers consider this a bug or a feature. IOW, will I be writing something that goes against the intended use or will this be a patch that just never got implemented.
The reason I'm asking is that there are two different strategies I can pursue to solve this problem. If Batik is intended to work as it does, my solution will be completely external to the factory, probably using org.xml.sax.helpers.NamespaceSupport and adding xmlns attributes to startElement() callbacks. If this is /not/ how Batik is intended to work, I will go into the sources and track where the factory is examining xmlns attributes and make it look at startPrefixMapping if no xmlns attributes are available.
Ari.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
