Re: getElementById method on SVGSVGElement

Thomas DeWeese wrote:

> Perhaps I missed the point of the question?

The point was very simple.  The current getElementById specification in SVG 1.1 
is severely underdefined.  This is easy to see from the fact that at least two 
separate implementors were not able to look at the definition and sit down and 
"correctly" implement it, since they could not tell what the function should do 
(those two would be me and you, since your initial comments about what the 
function should do clearly don't match what Batik actually does, which we can 
presume for the sake of argument is "correct").  As such, I would like the 
definition of the method to be clarified to the point where an implementor of 
SVG could reasonably implement it interoperably without having to resort to 
reading the code of other SVG implementations, testing other SVG implementation, 
or seeking clarification from the working group.

So all I am asking for are two things:

1)  That a full an consistent specification of the behavior of this method be
    written.
2)  That the resulting text replace the single vague paragraph currently present
    in the spec.

>    First note the use of the term 'document fragment' this is the
> name of the DOM object for a disconnected collection of Nodes,
> where as the mention of the document tree is in a parenthetical
> statement (and at that I'm not sure that such an independent
> set of nodes couldn't loosely be called a document tree - although
> admittedly that would be a little stretch).

The point is that the various parts of the sentence, parenthetical and not, are 
mutually contradictory unless one stretches the definitions of some of the terms 
to maybe (maybe) agree with others.  I would like for said contradictions to be 
eliminated.

Again, the point of having a _specification_ is to _specify_ what the behavior 
is.  If it's possible to read the specification and implement a behavior that is 
not explicitly prohibited by the specification but does not fit with the intent 
of the specification writer, then the specification is not doing its job.

Of course I'm assuming that the goal here is to have an SVG specification that 
is useful as something more than partial documentation of existing SVG 
implementations.  I've been told that my assumption is correct, but please do 
tell me if I've been informed incorrectly and I'll stop trying to get 
underdefined behavior defined.

-Boris