[prev in list] [next in list] [prev in thread] [next in thread] 

List:       calligra-devel
Subject:    Re: text:id is deprecated
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2011-12-15 15:24:24
Message-ID: 201112151624.25153.boud () valdyas ! org
[Download RAW message or body]

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.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


[prev in list] [next in list] [prev in thread] [next in thread]