On Sun, 2005-01-16 at 15:38, bulia byak wrote:
> On Sun, 16 Jan 2005 02:34:33 -0500, MenTaLguY <mental@...> wrote:
> > 1. it is now possible to remove the id attribute from an element
> So SPDocument::getObjectByRepr() won't work on it anymore? What is the
> preferred way to get at an element if not by id?
It still works. This was the reason why I made a separate
getObjectByRepr() (versus getObjectById()) and changed all the code that
didn't directly depend on IDs to use it so long ago in the first place.=20
[ SPDocument now maintains a direct SPRepr -> SPObject mapping table to
support this, in addition to the existing id table. ]
We still need ids for URI references (e.g. clones or gradient
references). Since we still give elements ids by default, users
shouldn't be affected unless they explicitly remove an object's id. The
object just wouldn't be accessible by URI reference until the user gives
it an ID again.
In the long-term we'll also allocate IDs for SVG elements on-demand, so
e.g. if an ID-less object is cloned it'll be assigned an ID
Note that allowing for non-ided elements was necessary, because we have
to deal with non-SVG-namespace elements where id may not be the right
name for XML ids, or IDs might not be part of the schema at all.
An example of such an issue is that we're sticking id=3D attributes in
RDF, where the ID attribute is supposed to be rdf:ID if you have IDs at
all (usually you won't). Now that we can support IDless elements it is
easier to stop mangling RDF in this way.
Another issue this has fixed is that text (literal text, not the <text>
element) and comment nodes no longer pollute the id namespace, since
they are no longer assigned IDs.
> > 2. manually setting a conflicting id now causes the original object to
> > get a new id, rather than disallowing the change
> You mean, some entirely different object that happens to have the same
> id will be renamed?
> I'm not sure it's a nice thing to do, especially
> without warning. At least in the places where this is accessible via
> UI (XML editor, obj props) there must be checks and warnings about
The Object Properties dialog hasn't changed -- it still prevents a user
from setting a conflicting ID.
As for the XML editor, I think there we must allow the user to do what
they want, but a warning is not a bad idea; I'm just not sure how best
to implement it yet.