W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

Re: Expected behavior on getFeature() when feature does not introduce a specialized interface?

From: Andrew Clover <and-w3@doxdesk.com>
Date: Tue, 6 Jan 2004 23:44:07 +0000
To: www-dom@w3.org
Message-ID: <20040106234407.GD488@doxdesk.com>

Curt Arnold <carnold@houston.rr.com> wrote:

> Validation does not introduce a specialized interface for DOM 
> implementations (neither does Events) and the spec does not give 
> explicit guidance to the expected return value. My instinct is that it 
> should be null.

Hmm. As the spec stands, I agree - the only alternative it could return a
non-implementation object associated with the feature such as a NodeEditVAL
or EventTarget, but without a document it is unclear where the object
instance would come from or what use it would be.

> Returns an object which implements the specialized APIs of the specified 
> feature and version, if any, or null if there is no object which 
> implements interfaces associated with that feature

> + or the feature does not define a specialization of DOMImplementation.

However non-DOMImplementation objects may also be returned (theoretically;
I haven't seen any DOM modules that actually use this - is the whole
hasFeature '+' business really a useful option?). The tricky bit is to tell
the difference between an interface that is intended to be returned from
getFeature but is not a specialisation of the owner interface, and
unrelated interfaces defined by the spec. IMO it should be up to each
module to state which extended interfaces are associated with which core
interfaces through getFeature, but currently Events and Validation don't
explicitly say.

Andrew Clover
Received on Tuesday, 6 January 2004 19:08:47 UTC

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