On Thursday, September 29, 2005, 6:18:06 PM, Thomas wrote: TD> 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. TD> What's the erratum going to say, "Sorry but that DTD thing is no TD> longer normative."? Or were you going to say that SVG is no longer TD> an XML grammar and implementations that apply the DTD (when present) TD> are not conformant SVG processors? ;) Its the implementations that apply the DTD when its not present that are the subject of discussion, really. Particularly when (as Robin points out) in some cases that makes the content non well formed. Its already clear from the 1.1 spec that content which omits the namespace declarations from the instance is non-conformant. Any erratum would therefore be aimed at conformant processors, when dealing with a) non-conformant content, or b) conformant content that does not have a DOCTYPE. I agree with Thomas that if the content includes a DOCTYPE and if a validating, or external subset fetching but non validating, parser is used on it then the fixed values in the DTD will be reported in the infoset. TD> Seriously isn't it a bit late to be saying things like that? TD> I'm happy with the "1.2" doesn't have DTD, and hence doesn't have TD> this issue solution, why do you feel the need to rewrite history? Perhaps the clarification above shows that history is not being rewritten. >> 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> TD> In point of fact Batik will treat this document correctly. We TD> simply provides a default SVG namespace decl when using the TD> SAXSVGDocumentFactory (it also ensures that the outermost TD> element is an svg:svg element when the parsing is done). If the TD> document want's to override this it can, if the document were to TD> reference the SVG DTD _then_ we would apply the SVG namespace to the TD> inner SVG element. TD> In this case since a conformant implementation can 'improperly' TD> interpret the content, then the content is at fault not the conformant TD> implementation. TD> Also I thought I had been very open about that fact that in the TD> 'no DTD' case I don't have strong feelings about Batik's behavior. OK, good. Since I do and Robin does and hopefully jwatt and tor still do, could we come to a resolution on the no DTD case? So, Batik will now complain if there are no namespace declarations in the instance, if the content has no DOCTYPE? That's excellent news. Its what Mozilla does now, and a firm stand here will encourage those other implementors who might be tempted to reverse-engineer bugs from the four year old ASV product. (Apparently a couple of them are tracking this discussion to decide which way to jump). As I understand it this would be a change for the current codebase - who is adding this? TD> At some point a while ago I noticed this behavior but it didn't feel TD> right to ignore the 'default' SVG xmlns attribute when a programmer TD> requested the parsing of an SVG document. On the one hand, a TD> human (the programmer) has said - this is an SVG document, parse it TD> as such, on the other hand the document in question may in fact not TD> be an SVG document (programmers do make mistakes ;) the factory does it's TD> best to make sure that the result matches the programmers expectation TD> (root element _must_ be an svg element in the svg namespace), but on TD> the other hand does do a little 'filling in the blanks' to try and TD> make the document meet the programmers expectation. If people TD> want to blast Batik for it's behavior in this case then fine, TD> but I think it's a huge mistake to extrapolate from the no-DTD TD> 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. TD> Very nice, except this isn't what Batik does. You should really test TD> 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. TD> 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. TD> So the real origin of this is that by default XML parsers in Java TD> fetch the external DTD, so for a very long time Batik did this. Which is conformant behavior for an implementation, but since its optional there are good reasons why SVG made this be non-conformant for content. TD> I didn't TD> see a good reason to suddenly make content that referenced the SVG TD> DTD fail (this is totally separate from the no-DTD handling issue). Because you are checking for a conformance requirement that is not expressed (or expressible) in the DTD, like Batik does in a bunch of other places. >> Batik is not technically non-conformant by implementing this behavior, TD> Thank you for clarifying that you agree that Batik's behavior is TD> conformant. >> but it is supportive of content written following very, very bad >> practices. TD> So should we support it when they turn on validation? Wouldn't TD> it seem odd to you that a document that fails when not validated TD> 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. TD> And it would be nice to solve world peace too. You TD> have access to the source, provide a clean patch and I'd be happy TD> to apply it. ;) Robin? (in your copious free time) >> You'll be doing your users a service, especially as that approach won't >> be legal for 1.2 content. TD> When they add 'version="1.2"' lots of things will change needing TD> to put the xmlns decl is just one of them, they can do that shortly TD> after they remove the reference to the SVG 1.1 DTD. ;) -- Chris Lilley mailto:[EMAIL PROTECTED] Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
