Re: Xerces-J2 CVS, Bugzilla, conformance issues

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
(http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-DocumentEvent-cr
eateEvent)

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

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

http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventListenerMa
nager.cpp#2325

> > 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
mistaken.

Received on Saturday, 11 August 2001 01:44:52 UTC