Hi Cameron,
Cameron McCormack wrote:
After some recent discussion about whether Mozilla's SVG implementation
will render SVG documents that omit the svg namespace declaration, I was
surprised to discover that Batik too accepted this. Isn't this
incorrect behaviour?
I suspect that you could ask 3 WG members and get 3 different
answers ;) Or in this case more appropriately you might be
able to ask 1 WG at 3 different times and get 3 different answers.
The relevant code that allows this is in SAXSVGDocumentFactory.startDocument.
Yes, exactly the _SVG_ Document Factory. If you look at the
official DTD for SVG 1.0 & 1.1 it says that any 'svg' element
(no prefix) automatically gets 'xmlns=".../svg"'. In other words
on can easily view the SVG standard as saying that any 'svg' element
with no prefix is automatically in the SVG namespace.
In the SVG 1.0 time frame I actually believe that this was
the active intent of the SVG WG, however since then the WG has
changed it's view to the "#FIXED 'xmlns'" was a mistake (and
perhaps it was).
If the DTD that predeclares the namespace were included, this would be
acceptable.
Does this mean that Batik is wrong to enforce any other of the
criteria for SVG validity unless the DTD is included? I don't think
so, IMHO an implementation of a standard is well within it's rights
to have some 'innate' knowledge of the DTD and 'enforce' it even when
if the content references a modified DTD that would allow the content.
So my question is: should Batik's behaviour be changed? If so, should
this content be disallowed completely (quite possibly breaking existing
content)? This would be consistent with the general strictness of
Batik.
In spite of my impassioned defense of the behavior above, I
really don't care (all my content includes the DTD & sets the
namespace). I don't think it's wrong for the SAXSVGDocumentFactory
(which BTW _requires_ that the root element of the document be an
'svg' element) to provide this namespace decl. However I can see
that in a world of multi-ns documents this behavior becomes
problematic (why does it work when it's a standalone doc but not
when I cut and paste it into my xhtml?).
Also (in case anyone was thinking it was) I don't think this
issue is particularly analogous to the Batik requirement that you
provide the SVG NS to create SVG Elements. The DOM spec is fairly
clear that createElement (no namespace) creates an element in the
'no namespace' which is clearly not the SVG NS (or the 'default'
namespace).
Or, should this content display some sort of warning (possibly
like the little yellow bar that appears in Firefox when popups are
blocked or if an appropraite plugin is not available)?
So my leaning would be towards leaving the behavior as is for
version 1.0 & 1.1 documents and either out right failing or
producing a warning for 1.2 documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
