W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2000

Re: Query about DOM standards

From: <keshlam@us.ibm.com>
Date: Sun, 11 Jun 2000 23:32:21 -0400
cc: www-dom@w3.org
Message-ID: <852568FC.00480B2C.00@D51MTA03.pok.ibm.com>
These questions may already have been answered, but...

>1) Will it be acceptable to replace the standard data members of a DOM
interface (like >nodename) with get and set mechanism

A DOM has no "standard data members". All DOM properties are accessed via
setter and getter methods. Remember, the DOM is _only_ an API; there is no
assurance that the structure of the data behind that API bears any
resemblence to the tree-of-nodes view presented by the DOM.

>2) Will it be acceptable to have one or more non-standard data members in
the private >section of the implementation of the DOM interfaces?

See above; data members are outside the scope of the DOM spec.

The DOM only defines the behavior of the DOM API. If your implementation
has other features as well, that's fine as long as the DOM APIs behave as
described in the spec. (It's not uncommon for DOM implementations to add a
few custom features. Of course any code which uses those features
sacrifices portability.)

>3)  What do we mean by readonly declaration of a DOM specification data

See above. A readonly attribute has a getter method but no setter.

>4)  Also I am making the assumption that the name of the implementation of
DOM >interface i.e. in the above case CDomNode (class name) can be

The abstract DOM interface should use the standard names. The class which
inherits/implements that interface may use any name that's appropriate, as
long as it can also be manipulated via the standardized name. (You may want
to take a look at some of the existing Java and C++ implementations for
examples. Or, perhaps, adapt one of those rather than creating your own
from scratch.)

Joe Kesselman  / IBM Research
Received on Monday, 12 June 2000 09:07:51 UTC

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