- From: John Bradley <john.bradley@kcl.ac.uk>
- Date: Thu, 7 Oct 1999 11:04:09 +0100 ()
- To: www-dom@w3.org
This is my issue also. It seems to me that the linking of elements by means of ID and IDrefs have been a part of SGML and XML from the very beginning and represent an element of the XML/SGML specification that so far seems to be ignored by the DOM builders. I confess to have less time to read these discussions than I would like and so am quite possibly missing some of its flavour, but is it fair to catorgise the discussion on this point and others as between software developers who are constructing software that implements DOM representations rather than by software developers who wish to use DOM representations for other application purposes? If so, then perhaps the reluctance to take on things like representing the ID/IDref link directly in the DOM may be understandable -- more work! However, for me -- someone who hoped that he could, relatively soon, take on a DOM implementation as the basis for a specific application -- the lack of support for such a basic part of XML as IDs and IDrefs is a serious problem. I'd also like to say that the most useful implementation for me of the ID-IDref link would not be by means of something like getElementById() -- although I guess getElementByID would be better than nothing -- since it seems to me that the DOM designers expected it to be based on some sort of name lookup and therefore implemented by, say, a lookup table behind the scenes. Instead, I had hoped that the DOM would recognise that the ID and IDref construct seems to represent a direct (and hopefully more efficient) link to the element that has the appropriate ID -- a true reference from one element to another. The interpretation of the attribute which was an IDref could then be as a reference to another element directly. The definition of IDs and IDrefs (going here from memory) which implies that for an XML or SGML document using IDs and IDrefs to be correctly constructed must have all IDrefs point to elements that actually have the IDs specified also implies that a useful way to interpret the ID/IDref construcct as something similar to a direct reference to the destination object. Actually forcing the application to invoke a name lookup to find the object seems rather inefficient -- although, as I mentioned above, perhaps better than nothing at all. Best wishes. ... john bradley -------------------------------------------------------------------- On Thu, 7 Oct 1999 10:50:06 +0900 Takuki Kamiya <kamiya@rp.open.cs.fujitsu.co.jp> wrote: > "Michael Champion" <michael_champion@ameritech.net> writes: > > > This is a semi-official Software AG response to the "Last Call" for comments > > on DOM Level 2: [I apologize to the WG for not raising this before the Last > > Call draft, but we agreed at the August meeting to take this to e-mail to > > figure out a solution for for Level 2; that discussion never happened, and > > since I was travelling for most of the rest of August I did not notice.] > > > > 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. There is a getElementById() > > method for HTML in DOM Level 1, and this is also needed by XML developers. > > Several DOM implementations, including Microsoft's widely used one, have > > such a method, and its lack in DOM Level 1 is often noted. > > > > I have been desperate for such a feature in DOM and concur it falls into > the category of information which many apps in general will aspire for through > pure DOM (as opposed to proprietary DOM). > > I'd like to point out that while getElementById() provides "a way of searching > node given an known id", "a way of discovering id" of an element is also > equally in need. (the name of which is, e.g. getIdAttributeName() ) > > = Takuki Kamiya Phone: (045)476-4586 Fax: (045)476-4749 = > = FUJITSU LIMITED (COINS:7128-4217 NIFTY:HHA01731) = > > ---------------------- John Bradley john.bradley@kcl.ac.uk
Received on Thursday, 7 October 1999 06:02:31 UTC