Thomas DeWeese:
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.
Cameron McCormack wrote:
But I think what determines if a document is an SVG document is whether
the document element is { "http://www.w3.org/2000/svg";, "svg" }.
This is a bit of an chicken and an egg statement. I'll say that
if someone uses the SAXSVGDocumentFactory that they have already decided
that the document being parsed is an SVG document, how they decided
that is (I think) out of the scope of discussion (mime-type?, file
extension?, user selected it from a list, it's the only format
supported ;).
That a DTD could enforce this is a side issue. Is it really allowable
behaviour for a UA to apply a DTD to a document even though there is no
DOCTYPE?
So should Batik not require an xlink:href attribute on an 'image'
element when the DTD isn't read?
Also, it seems that this FIXED namespace declaration is turned off in
the SVG 1.1 DTD (with an IGNORE).
I don't think so (although I must admit to being no DTD expert),
it looks to me like the IGNORE stuff is there so you can optionally
specify a prefix for the SVG element (i.e. 'svg:').
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.
That'd seem to make an SVG UA behave differently from a general XML
processing program.
Absolutely, we draw pictures ;)
But seriously we _do_ behave differently, one good example
is that we provide the correct default value for attributes
even when the DTD is not parsed:
<svg xmlns="http://www.w3.org/2000/svg"; height="100" width="100"
onload="alert(document.getRootElement().getAttribute('zoomAndPan'))"/>
I don't think you could be considered a conformant
SVG implementation if you didn't do this.
There are also many others (we check that that URL's
reference valid elements, we parse the CSS, you can call
'document.getRootElement()' from script). I understand that
these are a bit different but I honestly think it's a matter
of degree not kind.
I don't think it's wrong to require the document element to be an
'svg' element, since that's what the rec says makes an SVG
document/fragment. I just don't think it's the DTD which causes this.
The point I'm trying to make is that in my opinion SVG 1.0,
certainly, and 1.1, probably, specs intended that a conforming
implementation should treat an unadorned svg element as being
the SVG standards svg element, this intent is most clearly
expressed in the DTD.
I think reading/not-reading the DTD is a red herring. IMHO an
implementation of an XML standard is bound by the DTD for that
standard regardless of if the UA reads the DTD or not, it is
after all normative.
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.
Regardless of whether it's acceptable for the DTD to be applied even if
it's not explicitly referenced with a DOCTYPE, since it looks like SVG
1.2 won't have a DTD produced for it I suppose this would allow this
"stricter" behaviour, either way.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
