Hi,
sorry for intervening a bit late in this thread. There are a few things
that I think should be noted.
Thomas wrote:
Why by default? What happens when the Sonic Valve Gasket markup language
is styled with sXBL to create SVG?
Then hopefully they won't try and parse it with the
SAXSVGDocumentFactory which is intended to parse Scalable Vector
Graphics Documents.
But is so happens that a Scalable Vector Graphics document is allow to
contain foreign namespaces to its heart's content, and that 1.2 will
require sXBL support anyway. 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.
Jonathan wrote:
So it seems to me that in trying to use DTDs to require namespace
declarations *and* validate that those declaration's contain the correct
values (something DTDs appear incapable of doing), the SVG WG has
actually made it unnecessary to declare the SVG and XLink namespaces
when a doctype declaration is present. Would this be an unfair or
inaccurate assessment of the situation?
Given that processing the external DTD subset is optional even when the
DOCTYPE is present, this statement is somewhat inaccurate. Documents
that have a DOCTYPE declaring a default namespace and no explicit
namespace declaration actually have the dreaded heisen-namespace. This
is an endless cause for headaches and hard to spot bugs. Supporting this
is to be discouraged adamantly.
Cameron wrote:
I think the argument for this behaviour not occurring with SVG 1.2
documents in Batik is that the SVG WG is not going to produce a
normative DTD for SVG 1.2, so the namespace declarations will be
required (unless an explicitly referenced DTD does set them).
There will indeed be no DTD for SVG 1.2. DTDs are useless and dangerous,
they must be eliminated with extreme prejudice.
Thomas 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 ;).
Right, but they may have decided wrong! In this case an error (or at
least a warning) should be provided if the content is not what they
thought it should be. 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>
<animation>
The top animation tonight will be a strip-tease by well-known
SVG geeks at a bar after the conference.
</animation>
</svg>
</svg:g>
</svg:svg>
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. 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.
In general it should be noted that:
a) fetching the external subset (and processing it) is optional, so
content authored to rely on this is relying on optional processing. Note
that most Web implementations out there don't do that (and rightly so).
a') the implementation figuring out that it "knows better" what to do
in the absence of a DOCTYPE is even more optional, is likely to cause
bugs, and of debatable value.
b) there is no specification saying in which order DTD and namespace
processing have to occur. An implementation that would process
namespaces before DTDs (which isn't unreasonable) would not see the
defaulted attributes even if it fetched and processed the external subset.
c) there is a large amount of underspecification as to what happens if
one added an xmlns attribute after parsing (ie when the DOM is formed).
One implementation could have it apply to its scope based on known
prefixes (if there are any) while another could treat it as a DOM that
can only be serialized by munging the prefixes. (This applies in the b
case when the attribute defaulting happens post-namespace-processing).
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.
Batik is not technically non-conformant by implementing this behavior,
but it is supportive of content written following very, very bad
practices. 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. You'll be doing your
users a service, especially as that approach won't be legal for 1.2 content.
Thanks,
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
