Re: [dom3core] WRONG_DOCUMENT_ERR

On Wednesday 2005-11-30 17:10 -0800, Maciej Stachowiak wrote:
> The DOM Level 3 Core (and Level 1 and Level 2) spec requires  
> WRONG_DOCUMENT_ERR to be raised in many cases where a child is  
> inserted into a document other than its owner document, for example,  
> here for appendChild:
> 
> http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ 
> core.html#ID-184E7107
> 
> However, historically browser-based DOM implementations have let you  
> reparent elements freely, and there are in fact web sites out there  
> that create an element in one document and then insert it into  
> another. Safari actually limits the reparenting to the case of  
> elements that have never been in a document, to cover such sites.

I regret not getting around to testing WRONG_DOCUMENT_ERR when I wrote
http://dbaron.org/dom/test/one-core-html/exceptions back in the summer
of 1999.  https://bugzilla.mozilla.org/show_bug.cgi?id=47903 wasn't
filed until a year later, and it ended up never getting fixed.

> I'd like to request an erratum to make raising this exception  
> optional. There does not seem to be much benefit to requiring DOM  
> implementations to enforce this limit.

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?).  The authors of both of these classes value
interoperability within the classes but not between them.  (I've never
seen browser bug reports reporting that we don't interoperate with a
server-side DOM implementation.  Do server-side DOM implementations get
bug reports that they don't interoperate with browsers?)

These two classes of implementations originally had one spec, built to
meet two somewhat-competing sets of requirements.  However, this spec
wasn't tested thoroughly enough for the level of interoperability
required today (interoperability requirements increase over time -- it's
called "bug fixing"), and these two classes of implementations
separated.  It seems to me that this separation is probably permanent
and uncorrectable.  (At least it seems to me that it's uncorrectable
from the browser end; I can't say this authoritatively for the
server-side DOM implementation end.)

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?

Perhaps having to do this is unfortunate, although I'm not sure what the
original rationale for using the same interfaces for both browser and
server-side DOM implementations was, and other than losing that the main
cost is some extra spec writing and testing work.  What would have
prevented it is more serious testing:  thorough enough testing to
demonstrate real interoperability, which I think should be a requirement
for entering Proposed Recommendation, and which the CSS working group
now makes a requirement.  I think very few W3C groups have learned this
lesson, though.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation