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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
