Thomas DeWeese <[EMAIL PROTECTED]> writes: > Hi Ari, > > 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? > 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) 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 can see how this can be helpful for users who can't figure namespaces out (it's harder than it should have been, I know), but this is in violation of the Namespaces Rec (and it can't claim that it's pre-namespaces, because it interprets prefixed elements according to the Rec) > 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. > 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? Ari. -- Elections only count as free and trials as fair if you can lose money betting on the outcome. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
