W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1999

Re: DOM Level 2 needs getElementById method

From: David Brownell <david-b@pacbell.net>
Date: Fri, 08 Oct 1999 11:02:56 -0700
Message-ID: <37FE31D0.BB4ED2F0@pacbell.net>
To: www-dom@w3.org
keshlam@us.ibm.com wrote:
> >NOTATION declarations interact with at least two
> >things:  (1) attributes of type NOTATION, currently invisible in DOM;
> >(2) unparsed ENTITY objects, currently visible in DOM.
> True. But there's no DOM behavior associated with either case; the DOM has an
> architected way to define a notation, to recover it, and that's all.

Which is why it's so useless, even given Entity.getNotationName().

> In suggesting getByID, we're proposing a way to recover information with no way
> (yet) to either set it or derive it... in other words, a DOM behavior that a
> stand-alone DOM can not support without recourse to non-DOM methods.

You must have been reading some other mailing list than I was!

I saw lots of comments (including mine) which concurred on getElementById,
and then said that the rest of the API (to set/derive ID info) is needed
too.  In fact I don't think I saw anyone saying it's not needed; the only
negative feedback has been along the lines you've given, that the WG has
been holding its breath for schemas to happen.

> As I said, it's no worse than what was done with default attributes.  So if
> folks Really Need It, I'd be willing to see us go out on a limb, create a
> ContentModel feature (or some other name), and make
> DocumentContentModel.getElementByID the first

No, the precedent is that this method is on Document; see the HTML DOM.

And in fact this feature is completely unrelated to content models; it's
related to attribute declarations, not element declarations.  Consider

	<!DOCTYPE foo [ <!ATTLIST bar magic ID #REQUIRED>]>
	  <bar magic="one" attr='99 bugs'/>
	  <bar magic="two" attr='100 bugs'/>
	  <bar magic="omega">Fix a bug, check it in, 101 bugs...</bar>

No content models.  But four elements, three with ID attributes.

> I'd rather have a fully architected solution. But if folks really feel this one
> method needs to be rushed into production, I won't object to being overruled.

You already _were_ overruled ... ;-)

The proposal was to move the existing method into the core, and the feedback
so far has been "yes yes yes" along with "and make sure ID attributes are
not a 'Yet Another Backdoor API Needed' feature".

By the way, I seem to recall that this proposal was made last year too; it's
not a new one, users have asked for it for quite some time.  And wasn't the
ability to implement XPath using public APIs a requirement for L2 DOM?

- Dave
Received on Friday, 8 October 1999 14:03:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:28 UTC