text:id is deprecated

[Boudewijn Rempt]

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.

> > 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...)

> > In any case, I will go through our loading code today to check whether more
> > problems have appeared because of the text:id -> xml:id and draw:id ->
> > xml:id patches. In the past week in any case, any odt loaded and then
> > saved by Calligra was not just invalid ODF, but also invalid xml, since it
> > will have contained elements with two xml:id tags...
> 
> right that is definitely something that should not happen.

I'll go thoroughly through the code today and perhaps tomorrow as well.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl