xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From a..@lib.aero (K. Ari Krupnikov)
Subject Re: Transcoder as ContentHandler?
Date Mon, 01 Mar 2004 08:29:22 GMT
Thomas DeWeese <Thomas.DeWeese@Kodak.com> writes:

> Hi Ari,
>    So the answer to your question is, I don't know.
> The real question is how much would be broken if the
> code started to "trust" the code calling the ContentHandler? :)

Yes. You trust it for local names, why not for qnames?

>    I think I already identified one case where it wouldn't
> work properly (a 'raw' SVG file with no namespace decls
> or DTD specified).  This is I think an important case.

The only case where that would be appropriate is where no namespace
attributes have been defined on the outermost <svg> or any of its
ancestors. If an unprefixed svg element appears inside, say, a
<xhtml:p>, and there is no default namespace declared, the <svg>
cannot be interpreted as an element from the SVG namespace, it is an
element in a null namespace. (If the default namespace /is/ declared
and is not SVG, it certainly cannot be an SVG element)

Right now, it interprets any non-prefixed elements whose names match
SVG elements as svg, regardless of the declared default namespace. The
following is /not/ an SVG document no matter how you look at it, but I
get a pretty picture out of the transcoder.

<svg xmlns="non-svg" width="20" height="30">
  <circle r="10" style="stroke:black; fill:none"/>

I can see how this can be helpful for users who can't figure
namespaces out (it's harder than it should have been, I know), but
this is in violation of the Namespaces Rec (and it can't claim that
it's pre-namespaces, because it interprets prefixed elements according
to the Rec)

>    If the code can be constructed such that it handles this
> case and still properly respect the ContentHandler interface
> (which admittedly it is currently not doing a good job of)
> then that would be great.

Even if there is no DTD specified in a document, if the application
interprets it as an SVG document, it is in effect associating the SVG
DTD with the document. There is nothing that prevents it in this case
from defaulting attributes from the SVG DTD, which include default
vaules for xmlns and xmlns:xlink. That's OK, because SAX parsers are
not supposed to report defaulted attributes, only ones actually found
in the document.

>    I suppose one option is to keep the code mostly the
> same except have it use start/endPrefixMapping to update
> the namespace hash it maintains rather than parsing the
> attributes it's self (then it can still 'stuff' the
> namespace has with a default namespace).

That was the second approach I was talking about. There shouldn't need
to be any changes to the factory's heuristics (unless you want to make
it compliant with the namespaces rec). The only change would be that
it will respect startPrefixMapping() as much as it respects raw xmlns

A SAX parser reports startPrefixMapping for every xmlns attribute it
finds before it reports startElement for the element on which the
xmlns attribute was found. It saves the ContentHandler looping twice
through the attributes, first to update the map of currently declared
namespaces then to interpret the attributes according to this updated
context. startPrefixMapping is a direct replacement for manual
namespace attribute parsing. To have the factory take advantage of
this facility in the parser, you only need to override
startPrefixMapping in the factory to call the same code that is called
when it finds xmlns attributes.

>    Part of the issue is that I really trust the guys
> who wrote this code to know the DOM so I am loath
> to muck with it too much.  Any idea if SAX impls
> tend to 'mess up' start/endPrefixMapping?

Not to my knowledge, but I can ask people who know better. Can the
guys who wrote the code shed some light on it?


Elections only count as free and trials as fair if you can lose money
betting on the outcome.

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message