Robin Berjon wrote:
[...] It's a sad state of affairs that applying the DTD actually leads one to breaking conformance with the spec! But what's there is there and we have to handle the bugs that were introduced in the earlier XML vocabularies when no one had yet enough experience to identify such mistakes. I hope to submit a 1.1 erratum about this later this year.
What's the erratum going to say, "Sorry but that DTD thing is no longer normative."? Or were you going to say that SVG is no longer an XML grammar and implementations that apply the DTD (when present) are not conformant SVG processors? ;) Seriously isn't it a bit late to be saying things like that? I'm happy with the "1.2" doesn't have DTD, and hence doesn't have this issue solution, why do you feel the need to rewrite history?
Note that they may however be right in thinking that their document is SVG, and you could still be processing it in a non-conformant manner, viz:
<svg:svg xmlns:svg='.../svg'> <svg:g xmlns='http://example.org/SoVeryGoodML'> <svg>
In point of fact Batik will treat this document correctly. We simply provides a default SVG namespace decl when using the SAXSVGDocumentFactory (it also ensures that the outermost element is an svg:svg element when the parsing is done). If the document want's to override this it can, if the document were to reference the SVG DTD _then_ we would apply the SVG namespace to the inner SVG element. In this case since a conformant implementation can 'improperly' interpret the content, then the content is at fault not the conformant implementation. Also I thought I had been very open about that fact that in the 'no DTD' case I don't have strong feelings about Batik's behavior. At some point a while ago I noticed this behavior but it didn't feel right to ignore the 'default' SVG xmlns attribute when a programmer requested the parsing of an SVG document. On the one hand, a human (the programmer) has said - this is an SVG document, parse it as such, on the other hand the document in question may in fact not be an SVG document (programmers do make mistakes ;) the factory does it's best to make sure that the result matches the programmers expectation (root element _must_ be an svg element in the svg namespace), but on the other hand does do a little 'filling in the blanks' to try and make the document meet the programmers expectation. If people want to blast Batik for it's behavior in this case then fine, but I think it's a huge mistake to extrapolate from the no-DTD case to the with-DTD case.
Your enforcing of the DTD will cause an xmlns='.../svg' to be added not just to the root element (which would break nothing) but also to the embedded <svg>, which intended to be in another namespace thank you very much.
Very nice, except this isn't what Batik does. You should really test things like this before hand.
Any subsequent attempt at processing that document with, say, getElementsByTagNameNS() (or a bunch of other things) will fail, and you'll also report an error for the content of the inner svg element when in fact it is perfectly legal for it to be hanging out there.
Batik get's all this right, thank you very much. ;)
So at the end of the day implementing this behavior means that one processes content based on an optional feature (known to be debatable, and occasionally harmful) and two underspecified aspects of XML processing. It's taking granpa's hummer for a waltz on very thin ice.
So the real origin of this is that by default XML parsers in Java fetch the external DTD, so for a very long time Batik did this. I didn't see a good reason to suddenly make content that referenced the SVG DTD fail (this is totally separate from the no-DTD handling issue).
Batik is not technically non-conformant by implementing this behavior,
Thank you for clarifying that you agree that Batik's behavior is conformant.
but it is supportive of content written following very, very bad practices.
So should we support it when they turn on validation? Wouldn't it seem odd to you that a document that fails when not validated suddenly works in the same implementation when it is validated?
I understand that you may be loathe to remove this as it could break some content (though in a way that's easy for end users to fix), but at the very least provide a warning.
And it would be nice to solve world peace too. You have access to the source, provide a clean patch and I'd be happy to apply it. ;)
You'll be doing your users a service, especially as that approach won't be legal for 1.2 content.
When they add 'version="1.2"' lots of things will change needing to put the xmlns decl is just one of them, they can do that shortly after they remove the reference to the SVG 1.1 DTD. ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
