Re: [dom3core] WRONG_DOCUMENT_ERR

* L. David Baron wrote:
>I don't think an erratum to make something *optional* is the right
>solution.  (Likewise for the getAttribute discussion.)  What's happened
>here is that there are two classes of DOM implementations, Web browser
>implementations and server-side implementations (or is this latter class
>more than one class?).

This story is a bit too short, there are many browser-like applications
that provide DOM functionality to JavaScript scripts and other programs
through general purpose DOM implementations, e.g. MSXML is popular for
XML processing in Internet Explorer as well as XML processing elsewhere,
the Batik SVG browser uses Xerces which is popular elsewhere, too; the
SVG implementation SVG# implements the DOM simply by wrapping around the
.NET DOM implementation (getAttributeNS(...) is mapped to GetAttribute()
which takes a variable number of arguments), some people even use Perl
implementations like XML::DOM or XML::LibXML (a wrapper for libxml2) in
Internet Explorer. Plugins like the Adobe SVG viewer do not re-use the
partial DOM implementation of the hosting browser but have their own.

>So I think the solution here is not to make things optional.  I think
>it's to make the spec tell the truth:  that there are two distinct
>classes of implementations that follow slightly different rules.  The
>spec could define two separate conformance classes, and each class would
>be required to follow its respective rules.  What would we lose by doing
>this?  Who cares that the two classes of implementations interoperate?

Well, for SVG authors the truth is that they cannot rely on implicit
adoption (or a specific return value of getAttribute if the attribute is
not specified for that matter) for several years to come if they target
implementations currently available, most of which behave as required as
far as I can tell. SVG implementations don't fall into the server-side
class of implementations, so you can't really have this separation,
require specific behavior, and tell the truth at the same time for the
forseeable future.

If SVG implementations should support implicit adoption which might well
be the case considering ignorant developers who code only against some
non-compliant implementation with significant market share (like, say,
the Mozilla SVG implementation) the "server-side" implementations become
very significant, since popular implementations like Batik depend on
them, an implementation like Xerces would need a switch so it can behave
differently depending on whether it is in client or server mode, or the
Batik developers would have to find workarounds for the different re-
quirements.

Also note that changing the DOM specifications would not really help,
copy and paste specification authoring seems popular in SVG land and so
the SVG Tiny 1.2 and JSR 226 specifications would have to be changed
aswell in order to communicate such changes to the community.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 4 December 2005 04:19:52 UTC