xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Re: [svg-developers] Batik 1.5beta2 release available
Date Mon, 13 May 2002 11:36:47 GMT
>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

JL> I have no problem doing such a thing, but I believe a User Agent, is best
JL> served by rendering what it gets, and it should be liberal in doing that,
JL> the same way as Batik is happy to not use a validating parser, it would
JL> be good for users to treat createElement as creating an element in the
JL> default namespace. (after all the important thing is the content of the
JL> document, not if it's "correct")

    I know you've kind of taken it on the head for this comment... but
the comment deserves it :)

    Seriously, if what you want is interoperability[*] then the truly
important thing is that the content of the document be correct.  If
the content is not correct then you are in the land of implementation
dependent behavior.  The real problem is that until there are two
implementations there can't be a good sanity check for users that they
aren't depending on implementation specific behavior or bugs, as
opposed to what the specification says.  This is one of the reasons
Batik is so important, to try and give a "second opinion" on SVG

    Given the amount of heartburn this createElement vs
createElementNS has caused it might have been nice if the XML standard
had been more liberal (an element with no namespace adopts the
namespace of it's parent when inserted in a document. - Although even
that would cause weirdness on occasion).  However, once a standard has
declared conforming behavior, implementors of the standard must comply
doing anything else is a bug in the implementation (please see
Thierry's note on this).

    Bending the rules to match what another viewer does is the road to


[*] I realize that some people do not rate interoperability as very
    important.  IMHO they are usually being short sited to do so but
    in some cases it is an option.

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

View raw message