Purpose and scope of libs/odf

[Inge Wallin]

I have gotten some feedback to some of my later review requests that suggests 
that not everybody agrees on the scope of the ODF lib in libs/odf. I'd like to 
have a discussion here to clarify this and then write down the decision if we 
can come to one.

Current contents
-----------------------

If we look at what's in there at this time, we can find the following:

Lowest level
 * Basic ZIP store handling: KoStore, KoZipStore and some companion classes
 * Basic XML reading and writing: KoXmlReader, KoXmlWriter, KoDom
 * Basic ODF defines: KoXmlNS
 * Unit handling: KoUnit

Odf read/write level
 * Basic helpers for reading and writing styles: KoOdfStylesReader, 
KoStyleStack, KoGenStyle, KoGenStyles

Odf objects
 * Objects representing other parts of an ODF file than contents: 
KoOasisSettings, KoOdfManifestEntry
 * Simple objects that are common to many parts of an odf document and used in 
the applications: KoBorder, Ko3dScene, KoFontFace, ...
 * Style objects that are used only in some filters (the ooxml import filters): 
KoStyle, Ko*Style (several)
 * Objects that represent parts of an ODF document that are used only in 
filters. Applications have more sophisticated implementations that allow 
editing and with more efficient memory management: KoCell, KoColumn, ...

Notably absent are style objects that are used in applications.  The classes 
for text styles are in libs/kotext and some others are in libs/flake (e.g. 
KoMarker).

Proposed scope
----------------------

I think that the ODF library should be for people who need to read, write or 
handle ODF contents.  This means that all of the above is actually good 
examples of what should be in it. 

I think that libs/odf should contain more objects of the type KoBorder, etc, 
i.e. objects that are part of the typical content of an ODF file. I also think 
that we need to have remove the lack of style handling in libs/odf (see below 
[1]).  The style classes that are in there already are either for import 
filters meaning that they have setters and support for KoGenStyle or the ones 
by me which don't have full support for everything yet. It should not be too 
difficult to add loading to them and make them more generic. 

I want to work to make the odf library ready for external consumption.  I know 
what needs to be done here, but before I start on it in a structured way the 
final scope needs to be defined.


[1] About current style handling
-------------------------------------

Finally some words on the styles in libs/kotext:  These style objects are very 
efficient but totally tailored for a word processing application that uses 
QTextDocument for storage. They are not suitable for other types of use like 
filters and non-calligra applications. They also have some issues that I 
outline in [2], most importantly that they completely miss anything that is 
not about text. That text is a bit old but still mostly valid. We need 
something more generic in libs/odf, something that can be used stand-alone. 


[2] http://community.kde.org/Calligra/Architecture/Styles/Internals