Thomas DeWeese <[EMAIL PROTECTED]> writes:
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? :)
Yes. You trust it for local names, why not for qnames?
Actually we trust it for qname, we just don't trust it for the namespace. But the question still stands what will break?
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.
The only case where that would be appropriate is where no namespace attributes have been defined on the outermost <svg> or any of its ancestors. If an unprefixed svg element appears inside, say, a <xhtml:p>, and there is no default namespace declared, the <svg> cannot be interpreted as an element from the SVG namespace, it is an element in a null namespace. (If the default namespace /is/ declared and is not SVG, it certainly cannot be an SVG element)
Sure and we won't treat it as one.
Right now, it interprets any non-prefixed elements whose names match
SVG elements as svg, regardless of the declared default namespace. The following is /not/ an SVG document no matter how you look at it, but I get a pretty picture out of the transcoder.
> <svg xmlns="non-svg" width="20" height="30"> > <circle r="10" style="stroke:black; fill:none"/> > </svg>
I don't get a picture, I get the following exception, exactly as I would expect:
Enclosed Exception: Root element namespace does not match that requested: Requested: http://www.w3.org/2000/svg Found: non-svg
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.
Even if there is no DTD specified in a document, if the application interprets it as an SVG document, it is in effect associating the SVG DTD with the document. There is nothing that prevents it in this case from defaulting attributes from the SVG DTD, which include default vaules for xmlns and xmlns:xlink. That's OK, because SAX parsers are not supposed to report defaulted attributes, only ones actually found in the document.
This is in some sense what the code currently does, in absence of _any_ other indication the SAXSVGDocumentFactory assumes it has been given an SVG Document (this doesn't really apply for multi-ns docs).
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).
That was the second approach I was talking about. There shouldn't need to be any changes to the factory's heuristics (unless you want to make it compliant with the namespaces rec). The only change would be that it will respect startPrefixMapping() as much as it respects raw xmlns attributes.
A SAX parser reports startPrefixMapping for every xmlns attribute it finds before it reports startElement for the element on which the xmlns attribute was found. It saves the ContentHandler looping twice through the attributes, first to update the map of currently declared namespaces then to interpret the attributes according to this updated context. startPrefixMapping is a direct replacement for manual namespace attribute parsing. To have the factory take advantage of this facility in the parser, you only need to override startPrefixMapping in the factory to call the same code that is called when it finds xmlns attributes.
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?
Not to my knowledge, but I can ask people who know better. Can the guys who wrote the code shed some light on it?
I will try but they haven't participated much lately.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
