On Sun, 2005-01-16 at 15:38, bulia byak wrote:
On Sun, 16 Jan 2005 02:34:33 -0500, MenTaLguY <mental@...3...> wrote:
- 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. [ 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 automatically.
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= 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.
- 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?
Yes.
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 this.
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.
-mental