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

List:       koffice-devel
Subject:    Re: ODF Weekend: the vision
From:       "Ariya Hidayat" <ariya () kde ! org>
Date:       2007-05-10 15:30:19
Message-ID: ba035dd10705100830h6cd10f1dre01d90449468ed7b () mail ! gmail ! com
[Download RAW message or body]

> 2. My vision for the future of KDE is that OpenDocument will be a well
> integrated data format. This means that we have to do some design so that all
> applications can create, show or manipulate ODF data structures. We have a
> representative from Okular, (Tobias König) with us who will be our first user
> of this. If possible, it should be as easy to create a simple ODF document
> from a template as it is to play a sound using Phonon. Perhaps we should come
> up with a cool name for this technology.

I've been giving some thought about this in recent time.

Based on my experience handling several import/export filters (and
also collaboration with Abiword guys [1]), I suggest a two-layer
approach for the solution: the low-level and the high-level interface.
Think of SAX vs DOM (in context of XML processing).

The high-level interface is important for applications that just want
to load/save a document. This high-level interface must provide an
object model which is used to access the content of the documents.
Taking a spreadsheet as an example, the "user" of the library may do
something like (I'm just imagining the API here) :

  ODFLib::Spreadsheet s;
  s.load( "report.ods" );
  printf("There are %d sheets in this file", s.sheetCount();

The advantage here is the simplicity. However, it comes with some
price: the memory requirement might quite high _if_ the document is
quite complex and/or large, e.g a dissertation full of graphs,
equations, charts etc. If the application has internal data structure,
this is even worse because the whole thing consumes much more memory
than what is necessary.

Here, the low-level interface can be used by the advanced application.
If, e.g. the application has its own object model (for handling the
content), then it can "tap" into the low-level interface and process
the content as it's "streamed".

In this case, I can imagine a class responsible for loading the
content (e.g. ODFLib::SpreadsheetParser) and other abstract class for
the listener (e.g. ODFLib::SpreadsheetListener) which the application
must subclass. The listener class gets some sort of callback functions
(e.g. startSheet(const QString&name) and endSheet(const QString&
name)) which are used for processing and constructing its own object
model. Those who are familiar with QXmlDefaultHandler must know what I
mean here. Another good working example of this is libwpd: see
WP6Listener.h [2] and WordPerfectCollector.* [3].

Of course there are opposing views for this approach. For example,
while streaming low-level XML events (startElement, endElement in
QXmlDefaultHandler) seems to be logical for processing XML document,
streaming document elements are really not so obvious. Not too
mention, due the style handling of ODF, we may need to parse some XML
more than once (or do some necessary preprocessing).

As for cool name, let me have a try [4]. How about "Seaport" or
"Haven"? ODF is about document interchange, analog to what happens to
cargos in a seaport.

Regards,

Ariya


[1] Take at look at libwpd and its API. libwpd is used in KWord,
Abiword and OpenOffice.org
[2] http://libwpd.cvs.sourceforge.net/libwpd/libwpd2/src/lib/WP6Listener.h
[3] http://libwpd.cvs.sourceforge.net/libwpd/wpd2sxw/src/WordPerfectCollector.h
[4] I must admit, this is influenced by my recent trip to Hamburg :-)
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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