Re: DOM Level 2 needs getElementById method

Michael Champion wrote:
> 
> We believe that it is important to have a method in DOM Level 2 to get an
> element by the value of its ID attribute. 

Yes.

 
> The DOM Working Group has considered this issue on several occasions; the
> general feeling has always been that a)  this could only work for XML
> documents that have a DTD, and the DOM (like XML) does not require a DTD ;

That didn't prevent adding various other features which required some
DTD knowledge, such as exposing NOTATION and ENTITY information or
having specialized handling for attributes with default values.  So
I can't see any good reason to accept that.



> So, I'm suggesting that to the Document interface, add the method
> 
> Element getElementById(in DOMString elementId)
> "Returns the Element whose ID is given by elementId.  If no such element
> exists, return null.  Behavior is not defined if more than one element has
> the id."
> 
> So, do people on this list support this idea? 

Yes -- I've made such proposals myself, too.  There's a method naming
issue, it can't reuse the name from the HTML DOM since it's got a
different return type, but that's fixable.


>	 Is returning null the right
> solution for the situation where there is no ID defined *or* no element
> matches the specified ID?  Does it make *practical* sense to distinguish
> these two situations? 

I'd prefer to see one distinction made, getting an exception report
when the DOM can't support such lookups (e.g. it has no attribute typing
information).  I don't much care about distinguishing the "DTD has no IDs"
case from the "document doesn't have that particular ID" case.


>	 Is this an excessive burden on DOM implementors?

The main burden I can think of is that since this is the first _useful_
example of DTD-related information, I'd like to ensure that it doesn't 
require Yet Another Backdoor Proprietary API.  The absolute requirement
for such APIs is one of the fundamental problems with DOM as an API,
and I can testify to that as both a user and implementor of DOM.

That is, it should be paired with methods to put attribute typing
information into a DocumentType object.  I can put together a proposal
in that space, which would start to address the oft-repeated "we need to
see document type information in the DocumentType interface" complaint.

Note that at this point I can't support the notion that "schemas will
solve everything"; I can't see a benefit to delaying real DTD support.
It'll still be needed after schemas finally arrive.

- Dave

Received on Tuesday, 5 October 1999 17:09:26 UTC