Re: getElementById method on SVGSVGElement

Thomas DeWeese wrote:
> Robin Berjon wrote:
>> Thomas DeWeese wrote:
>>> If the node is in the document then all of it's
>>> nodes are reachable from all other nodes in the document and thus
>>> the id's in the SVG element's subtree must not duplicate any in the
>>> rest of the document tree.  I don't think this part is any different
>>> from the behavior of any existing conforming DOM implementation.
>>
>> Do you have a reference for this? 
> 
>    No. So, you would consider my example code to be in error?

By having two elements with the same ID? No, that's not a DOM error :) 
The behaviour of the DOM under such circumstances is undefined.

> If so there is no way to reuse an id and keep the document
> consistent in the process, at some point the id which may
> be referenced must be undefined.  This introduces all sorts
> of interesting issues about how/when an SVG document can be
> "invalid".

There are *many*, *many* situations in which it is if not difficult at 
least impossible to maintain a document in a way that the target 
language would consider consistent (if only based on some schema 
validation) by manipulating the DOM. DOM 3 Validation goes into some 
(but not much) detail to explain these sorts of problems. Ideally one 
would have some form of transaction support to define which changes are 
atomic (this would actually probably enable some interesting 
optimizations for DOM implementers) but there's no such thing, and users 
wouldn't use it anyway.

>> Based on that, I would expect that given element 'el' not attached to 
>> the tree but belonging to document 'doc' 
> 
>    But I see no requirement on the ownerElement belonging to
> 'doc', or that ownerElement be in the same processes or even on the
> same machine, so following your logic a DOM implementation must
> search every machine in existence for an element with that id.
> I knew id's had to be unique but I didn't realize they had to GUIDs ;)

Nah, you're stretching my argument :) There is indeed no argument 
stating that the element be in the same process or machine — you could 
well have a distributed DOM. What I'm saying is that it is a very 
reasonable (and I believe, common) implementation strategy to cache all 
IDs in a table that maps them to their elements — otherwise you have to 
perform a linear search of the entire document to get at an ID, which 
sort of nullifies the advantage of having IDs (instead of, say, running 
an XPath query) in the first place. A highly likely position in which to 
maintain such a table is in the methods that manipulate attributes as 
well as setIdAttribute* and importNode. Since I see no requirement that 
the element be attached to the tree in order to be returned by gEbId, 
and since maintaining the ID table for all element manipulations is 
likely to be so costly that you wouldn't want to have the table at all, 
I would assume it to be an unreasonable expectation to think that 
elements belonging to the document but not attached to it will 
interoperably never be returned.

It's the spec doesn't even say the returned element needs to have 
ownerDocument be the same document that the message was sent to, but I 
would consider it unreasonable if it weren't the case, and a reasonable 
expectation that it is :)

>> and having an attribute 'foo' of value 'bar', if I did 
>> el.setIdAttribute('foo', true) it appears to be expected that 
>> doc.getElementById('bar') would return el.
> 
>    Clearly there is some subset of the DOM universe that
> is expected to be searched, I don't see a clear indication of
> that that universe is from the DOM spec.  I personally find it
> quite a stretch to extend the search to all nodes ever created
> by a document (does it hold 'hard' references to them?).

It's not "ever created" since some of those may have been imported by 
another document, or destroyed entirely, but rather those that have 
their ownerDocument set to that given document. And it's not nodes but 
just elements.

>    It is probably time to request a clarification from the DOM WG.

The DOM WG? What DOM WG?

-- 
Robin Berjon
   Research Scientist
   Expway, http://expway.com/

Received on Monday, 7 February 2005 13:21:06 UTC