#2 Non-conformant DOMException accepted
Robert Clary wrote
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0155.html
...
Concerns regarding Browser/Vendor specific workarounds
The current DOM TS provides work arounds for specific
implementations which do not adequately implement
the DOM Specification. These workarounds allow the
implementation to 'appear' to pass the conformance
tests even though in actuality they do not.
...
Example - DOMException
----
Internet Explorer/MSXML do not implement the
DOMException interface however the DOM TS provides a
mapping from Internet Explorer/MSXML's
proprietary exceptions into the DOMException
specification and hides Internet Explorer's lack of
conformance.
While providing a 'compatible' or 'equivalence' mode
for tests for an implementation in order to provide
as much information to the implementation's
developers as well as users of the implementation is
appropriate and should be included in the DOM TS, any
such workarounds should be clearly delineated from
the actual Conformance Tests and be clearly labeled
so as to not mislead users of the Conformance tests
as to what is or is not a Standard.
All implementations should be judged equally with
regard to conformance and not have the issues
involved confused by such workarounds.
Logged In: YES
user_id=27193
Dimitris Dimitriadis <dimitris@ontologicon.com> wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0156.html
Also correct, in part. Here we enter a gray zone, as the
DOM Specification only dictated what should be done, and
not how. So, in those cases where it is obvious that the
DOM specification is not followed, you're right. However,
the DOM specification is flexible isnofar as it provides a
wrapper around any implementation and is to be judged by
behaviour.
...
I indicated that there can be grey zones above. However,
where we identify such levels of difference from the DOM
Specification, it should certainly be discussed.
Logged In: YES
user_id=27193
Jason Brittsan wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0157.html
Comments regarding DOMExceptions:
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-
one-core.html#ID-17189187
<quote>
Some languages and object systems do not support the
concept of exceptions. For such systems, error conditions
may be indicated using native error reporting mechanisms.
For some bindings, for example, methods may return error
codes similar to those listed in the corresponding method
descriptions.
</quote>
By returning error codes, Internet Explorer does conform
to the DOM Level 1 specification.
Logged In: YES
user_id=27193
Robert Clary wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0159.html
Internet Explorer/ECMAScript can and does throw
exceptions. It does not fall into the category of systems
that do not support the concept of exceptions. It simply
does not implement the DOMException interface.
Logged In: YES
user_id=27193
Curt Arnold wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0161.html
This is a reasonable cop and should be clearly labelled.
MSXML is a COM parser and Microsoft's COM/Scripting
interoperability layer provides no mechanism (at least as
far as I can determine) for a COM component to throw an
exception with a code attribute. The approach of the
current adaption layer mimics the original NIST ECMAScript
testing framework which was forgiving of this deviation
(actually it required everybody else to conform with this
deviation).
That said any COM implementation (MSXML, Apache-C's COM
wrapper and Adobe SVG's control, for example) accessed
from Microsoft's implementation of ECMAScript CANNOT be
compliant with the ECMAScript binding's definition of
DOMException.
It would preferred at least that MSXML use HRESULT's that
had a direct correspondance with the DOMException.code
values. I believe that Adobe SVG and the Apache-C COM
wrapper do have direct mapping between the values (you
have to mask off the high bits to get the
DOMException.code value).
Logged In: YES
user_id=27193
Robert Clary wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Feb/0163.html
COM may not allow exceptions however the mapping of
HRESULTS to Exceptions in ECMAScript is possible, and is
the basis for the cross language support of COM and is
accomplished in Internet Explorer/MSXML..
>
>How does Mozilla deal with exceptions?
>
[bc]
I have asked one of our developers to address this in more
detail.
But let me say that Mozilla is based upon xpCOM which is
based upon the same principles as COM.
xpCOM does not allow exceptions any more than COM does.
However, mozilla.org contributers made certain to throw a
DOMException which included the standard code attribute.
See
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/core
/nsIDOMDOMException.idl#58 for the interface definition of
DOM Exceptions in Mozilla.
Non standard DOMExceptions only make the life of web
developers more difficult. If you were a web developer
and had to choose between the W3 DOMException Interface
which only Mozilla implements or the proprietary one
Internet Explorer implements, which would you choose?
Logged In: YES
user_id=27193
Dimitris Dimitradis wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Mar/0002.html
Exception handling: The DOM WG resolution is this: The DOM
is defined for ECMA, which supports exceptions.
Therefore, any DOM implementation for ECMA script should
support this feature. The previously sent email to this
list by Jason Brittsan contained the following (I'm
currently in a plane and cannot look up the archives):
Comments regarding DOMExceptions:
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-
one-core.html#ID-17189187
<quote>
Some languages and object systems do not support the
concept of exceptions. For such systems, error conditions
may be indicated using native error reporting mechanisms.
For some bindings, for example, methods may return error
codes similar to those listed in the corresponding method
descriptions.
</quote>
By returning error codes, Internet Explorer does conform
to the DOM Level 1 specification.
Given that ECMA is not a language that does not support
exceptions, a system that is built with ECMA support and
does not support exceptions cannot be considered
conformant to the DOM. If a system does not use ECMA and
therefore not exceptions, it is a non-issue for the DOM
WG. Thus, the DOM TS framework will be rewritten and the
workaraound must be removed.
Logged In: YES
user_id=27193
Curt Arnold wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2002Mar/0004.html:
Changed in DOMTestCase.js rev 1.14.
DocumentBuilder.isDOMExceptionCode(ex,code) now returns
(ex.code == code). This results in every test where an
expection is anticipated to fail for all COM-based
implementations accessed from JScript.