text:id is deprecated

[Thorsten Zachmann]

On Thursday, December 15, 2011 10:38:42 Boudewijn Rempt wrote:
> On Thursday 15 December 2011 Dec, Thorsten Zachmann wrote:
> > On Thursday, December 15, 2011 09:14:28 Boudewijn Rempt wrote:
> > > On Thursday 15 December 2011 Dec, Thorsten Zachmann wrote:
> > > > for me this looks like a bit of overkill. Let me explain how the id
> > > > stuff in the animations work.
> > > 
> > > Right now, for animations, draw:id is used, isn't it?
> > 
> > right but it should use xml:id when we are finished with that.
> 
> Ok.
> 
> > > > The xml id is not kept. It is only used during loading to
> > > > be able to get the thinks it refers to. The e.g. we get us the shape
> > > > for the id and store the shape. The when writing out the stuff a id
> > > > is generated and we get the id again. During the runtime of the
> > > > program the xml:id is not usefull at all. That is also the case for
> > > > the places where the other id's are used.
> > > > 
> > > > Maybe the rdf stuff can use a same mechanism. That would also solve
> > > > your problem that it thinks all xml:id tags are used for rdf.
> > > 
> > > One big issue I have is that it is possible to identify an element with
> > > xml:id for more than one purpose, yet you can have only one id per
> > > element. Right now, all shapes appear to be tagged with draw:id. That
> > > should become xml:id. If I also want to tag that shape with rdf, I have
> > > to re-use the same id.
> > 
> > Looks I was not clear here. I think we should not identify the usage of
> > the xml:id with the content. More e.g. use shape1 for a xml:id of a
> > shape. If that is used in a animation or for rdf does not matter.
> 
> Hm... I would prefer a uuid myself for easier searching. Right now, we have
> id's that are only unique within context, like subitemN. And having
> something that identifies the type of element the id belongs to is on the
> one hand liable to misuse because someone _will_ come along and think they
> can use that part in their code, and on the other hand it doesn't help
> much, since we already know that we're loading, e.g. a shape.

we need to support the loading also for the xml:id that other apps provide and 
they don't use uuids as xml:id.
> 
> > > It's what we do now, as a temporary measure, so I check whether the
> > > xml:id starts with rdfid- and then assume it's for rdf.
> > 
> > And that should go. The rdf stuff should use the same mechanism as e.g.
> > the animations and resolve the ids during loading. There is already some
> > code for that. It might work or need to be expanded.
> 
> Well, no... Not that I could find. In fact, until yesterday encountering an
> xml:id when loading text or bookmarks always means "aha! rdf!", and the
> loading code doesn't have access to the rdf document, which it could use
> to figure out whether the id occurs in the rdf store as well. (I notice
> that KoTextMeta can save itself, but not load...)

Then this needs fixing. I think we should not keep the xml:ids around in the 
loaded document.

Can you explain a bit more what the problem is here?

Thorsten