Re: [dom3core] WRONG_DOCUMENT_ERR

On Dec 2, 2005, at 11:34 PM, 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?). 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?)
With load and save, there could easily be code expected to be shared 
between client and server.
Convince Sun to support a separate Java implementation behavior for 
browsers and servers, which can get bound in to browser javascript, 
not unlike possible xpconnect binding for languages that might 
otherwise be used on the server or server side Javascript. It is 
anyone's guess what Applets or standalone applications do for DOM.
Perhaps this is not considered mainstream stuff at present, but those 
who were following the existing standard may get rather upset anyway 
and it gets quite messy to define.
> So I think the solution here is not to make things optional.
Unless it could be interpreted to be already optional, see my prior 
note.
> 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?
Does this make WRONG_DOCUMENT_ERR optionally thrown in the browser or 
are most operations just completely undefined with respect to what is 
likely to happen in the browser because no one will fix the 
implementations to throw the appropriate exception? There are cases 
in browsers, including Mozilla as I last knew of it and I believe IE 
as well, where the nodes are not compatible to cross between document 
boundaries because an HTML DOM is not compatible with an XML DOM, 
etc., but they probably don't throw the correct error now.
> 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.
It requires a new standard, as occurred with HTML DOM Level 2, which 
is incompatible with HTML DOM Level 1, which had significant mistakes 
which I requested (at the request of others) the W3C to delay to 
ultimately make incompatible to fix the problems recognized up until 
that time, which then proceeded and made the standard quite late.
> 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.
DOM clearly didn't test until level 3, which now has a test suite 
that contains level 1 tests to test these particular cases, and I 
believe there are probably still many missing tests which would 
expose more common differences between the implementations and the 
standard because such testing of finite cases is inherently 
incomplete in the infinite set of inputs and outputs. It would have 
significantly delayed DOM Level 1, but saved time later.
But the question seems to be as much about intentional drift as 
incorrect initial implementations. The big question is commitment of 
dominant players to set the expectation. I believe that the Mozilla 
code base defining and initially implementing DOM Level 1 had a JS 
binding mechanism that couldn't return a null in a string return, 
such that getAttribute was initially previously completely correctly 
implemented as defined. It certainly wasn't the users of the Java 
binding who asked for that non-null string return -- but they are the 
ones expected to keep it while Mozilla apparently chases later IE 
improvisations rather than keeping the original correct standard 
implementation.
I say turn the finger around because dominant browser vendors need to 
take more responsibility, as the test platform for web content, to 
enable web authors to easily distinguish good content from broken. 
If it were possible to clearly communicate to web authors testing 
against a browser the problem with their content, fixing content is 
feasible and preferable. Being compatible/tolerant for end users 
shouldn't preclude this or it encourages very broken content. The 
worst known flaws with common implementations could also be 
identified allowing avoidance -- standards evangelism backed by 
appropriate tools. A web author strict checking mode for browsers 
would seem to be called for. It could even help to deal with 
inevitable incompatibilities between browser versions. Yes, it is 
more difficult than this explanation I have given, but the resulting 
better web content is worth it.
As has been pointed out, this is hardly the first case in which this 
has occurred and there is no reason to believe it is the last just 
because they are the only ones currently highlighted by tests. I 
believe that reconciliation must become possible by changing the 
browser implementations and wielding more influence with authors by 
providing a less-treacherous test platform for them. These particular 
cases we have before us today hardly occur in most content, and once 
a maintainer has identified the problem, it is not hard to devise 
alternative mechanisms that avoid known browser bugs.
Ray Whitmer

Received on Saturday, 3 December 2005 09:55:53 UTC

AltStyle によって変換されたページ (->オリジナル) /