text:id is deprecated

[Jos van den Oever]

On Thursday, December 15, 2011 16:24:24 PM Boudewijn Rempt wrote:
> On Thursday 15 December 2011 Dec, Jos van den Oever wrote:
> > On Thursday, December 15, 2011 11:21:19 AM Thorsten Zachmann wrote:
> > > > 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?
> > 
> > The xml:id is there because some part of the document references the
> > element. This reference should be present in some form. One form would
> > be to have a common way to reference that can be serialize as unique
> > id's. Since different parts of Calligra could reference a particular
> > element and this reference is written as xml:id, a common registry for
> > these references is needed.
> 
> It turns out that currently, only the rdf system keeps the actual id
> strings after loading is finished, the other parts of calligra only use
> the id strings to build their mappings during loading, and recreate them
> during saving.
> 
> > Each element could suggest a prefix to make it easier to read, but the
> > prefix should be chosen by element and not by the code that references
> > it, since multiple parts could reference it.
> > 
> > A tricky part will turn out to be to make sure that keeping a reference
> > does not prevent delation. QWeakPointer could fit this role.
> 
> Well, for that I proposed yesterday to use QSharedDataPointer -- i.e., make
> the whole system work just like QString or QImage, but without the ability
> to get/set the actual identifying part out of the reference.
> 
> I've got sort of an action plan now:
> 
> 1. Saving
> 
> * check all code that saves draw:id and text:id and make it also save
> xml:id * keep track of the list of generated xml:id's and make double sure
> they are always unique. (I still would prefer uuids, like used for lists
> and rdf, but failed to convince zagge :-) * only save xml:id (formerly
> text:id) for KoTextBlockData if the kotextblockdata is actually used for
> animation. * make sure that even if two cross-references want an xml-id to
> be written to an element, that the links in other parts of the document
> are correct.
> 
> 2. Loading
> 
> * fix the places where we use getAttribute("id") to be
> getAttributeNS(KoXmlNS:xml, "id"); * check all that loads draw:id or
> text:id and make it load xml:id first, if present, if not, fall back on
> draw:id and text:id. * first load the objects that the xml:id's in the
> body may refer to, so can build the cross-references on loading
> 
> 2. RDF
> 
> * make the KoDocumentRdf instance available to the
> KoDocumentResourceManager * make KoDocumentRdf create a list of all
> xml:id's that are used in manifest.rdf * on loading, when encountering an
> xml:id, check whether it's present in that list *   if so, create the
> KoTextInlineRdf object, if not, don't (replaces the check for rdfid- in
> the xml:id string) * replace keeping the xml-id string with an
> ElementReference class that can be used during runtime, so we don't have
> to do the complex xmlid rebasing after saving we do now. * make KoTextMeta
> actually load and save, since that was never implemented...
> 
> In passing: it would be good if we could directly attach rdf metadata to an
> element (like text:table) instead of always having to work with bookmarks.
> 
> 3. KoTextBlockData
> 
> This class causes a text:id to be saved in all cases, but it's only
> relevant when animations have been added. So, only then should we save the
> xml:id.

I generally like the plan and could not find any problem. A question though: 
would the classes KoElementReferenceData know if there are any 
KoElementReference instances that point to it? If there aren't any, there is 
no need to write the xmlid.

Cheers,
Jos