W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: Xerces-J2 CVS, Bugzilla, conformance issues

From: Curt Arnold <carnold@houston.rr.com>
Date: Sat, 11 Aug 2001 00:44:33 -0500
Message-ID: <00c201c12228$b313a590$a800a8c0@CurtMicron>
To: <xerces-j-dev@xml.apache.org>
Cc: <www-dom@w3.org>
From: "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
> > Two of the tests check if the feature name check is case-insensitive
> > which is vague at best in the DOM Events spec.
> This is actually clearly specified in the core spec which is were
> hasFeature is defined:
> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-5CED94D7
> >  In the resolution to
> > bug 1814, it was basically decided that your reading was that the
> > event types were to be compared case-sensitive.
> That is also very clearly specified in the Event spec. There is no room
> for interpretation:
> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-type

Actually, neither of those are directly on point.  The issue is whether
values are acceptible for the eventType argument for
DocumentEvent.createEvent where there are inconsistencies in the description
of the argument

"The eventType parameter specifies the type of Event interface to be

This sentence in isolation would suggest the argument should be some text
representation of an interface that must be supported by the created event,
for example "Event", "MutationEvent", "UIEvent", "MouseEvent" would be
reasonable interpretations.  Since interface names are case sensitive, this
interpretation would suggest that "event" would not be treated the same as
"Event".  This was the interpretation in the development of the Xerces-J
code base.

"As an example, a user wishing to synthesize some kind of UIEvent would call
createEvent with the parameter "UIEvents".

This example suggests that the argument should be the corresponding feature
name (note the explicit trailing "s") and feature names are intepreted (at
least in the context of DOMImplementation) as case-insensitive which would
suggest that DocumentEvent.createEvent("uievents") should work also.  That
was my and Mozilla's interpretation, they perform a case-insensitive
comparison based on feature names (and reject interface names) at


> > The third test checks removing an event listener in the middle of an
> > event dispatch sequence.  The spec says that a listener should recieve
> > no events after removal.
> You're right there, that's what the spec currently says. But the spec is
> wrong, though. It is meant to say the opposite. I just double-checked
> with Joe Kesselman who was very much involved in the development of that
> spec and who implemented it in Xerces and he confirmed my fears.
> I will bring it up to the DOM Working Group, I would expect an erratum
> to be published.

I had to jump through some serious hoops to implement it as written in my
personal Xerces-C DOM Events implementation.

> > Overall the events implementation seems much improved over Xerces-J 1.
> Unless regressions were introduced in Xerces-J 1 I don't see how this is
> possible. The DOM implementation in X2 is the same as the one X1 except
> for the Deferred DOM which was taken out. The only diff is that the code
> hasn't been merged for a while so the version in X2 is outdated.

Sorry, that was based on a vague recollection and I definitely could be
Received on Saturday, 11 August 2001 01:44:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC