Re: First patches for the OpenDocument plugin

Hi Rob,

Robert Staudinger wrote:
>
> I read the metadata parser part of the patch (assuming that the
> .cpp/.h split part is ok). It looks good to me. Only the relation
> between "meta:initial-creator" and "dc:creator" is not clear to me.
> Can they both be set at a time with different values and what does
> that mean? You really need to convince me that both are needed in
> AbiWord, like you indicated in the patch.

Quoting the "Open Document Format for Office Applications (OpenDocument)
v1.0":

"The <dc:creator> element specifies the name of the person who last
modified the document.
[...]
The <meta:initial-creator> element specifies the name of the person who
created the document initially."

Dublin core gives a somewhat abstract meaning to <dc:creator>,
OpenDocument just makes it more strict.

The dublincore.org definition for <dc:creator>:
"An entity primarily responsible for making the content of the resource."

>
> For stuff like that:
> + // Should have a PD_META_KEY_INITIAL_CREATOR macro for this one
> + getDocument()->setMetaDataProp("meta:initial-creator", m_charData);
> feel free to send a patch too. Also i'm not sure if we'd like to start
> using namespaces in the metadata section or if a simple "meta." prefix
> would do as well for properties that go beyond Dublin Core.

The OpenDocument standard use the "meta." namespace for its so called
"pre-defined metadata" that does not come from Dublin Core (<dc.*>).

It is interesting to note that OpenDocument uses just about half of the
 Dublin Core metas.

In my opinion, it would be interesting to define new PD_META_KEY_*
macros for those new OpenDocument metas only if they could be
accessed/viewed/modified by the user interface (on the file properties
dialog). Is that right?

>
> Another thing we previously discussed was to store the entire settings
> stream in a metadata attribute so we could regenerate it on export
> (AbiWord doesn't excessively store its settings in the documents).
> Maybe you'd like to look into that?
>

I think that the settings should just be parsed at import and discarded.
By "parsing", I mean that they should be used to configure AbiWord's
workspace, like the current cursor position in the document, the zoom
factor, etc.

Then, when you save/export a document, the settings stream will be
generated by getting info about the current AbiWord's workspace state.

Today, the settings stream does just the right thing, that is, ignores
the settings stream entirely. This is right because nowadays all the
settings we read are like "ooo:view-settings" and
"ooo:configuration-settings". Those settings refers only to the
OpenOffice.org application suite and we have nothing to do with it. So,
after opening and modifying a OpenDocument file that was last modified
by OOo (OpenOffice.org) we will save it with a brand new settings
stream, containing info only about the AbiWord's workspace state at the
time that this file was saved.

Being so, the new settings elements would be named like
"abiword:view-settings", "abiword:configuration-settings",
abiword:anything-we-might-want" and thus would be ignored by OOo when it
 opens this file, just like we did with his.

The problem is that in order to do this we must first define the
AbiWord's settings structure to be used on OpenDocument files.

Personally, I think that is important to focus first on the import of
the document contents (finish its implementation) and later on the
settings. So, at the time we have AbiWord reading OpenDocument files
nicely we may rise the discussion about the AbiWord settings structure
for the OpenDocument standard.

Best regards,
Daniel d'Andrada T. de Carvalho - INdT
Received on Mon Jul 4 17:12:40 2005