RFC: ideas for a simple OpenDocument API

[Kevin Krammer]

On Wednesday 27 December 2006 11:41, Thomas Zander wrote:
> On Saturday 23 December 2006 12:09, Kevin Krammer wrote:
> > I agree that roundtrip capability would be very nice, however I'd rather
> > have this limitation than having to deal with a full blown OpenDocument
> > API for just simple tranfers.
>
> There is a similar idea thats been floating around the minds of various ODF
> people for some time.
> The idea to have an ODF API so you can inserts a stream and instead of the
> normal sax/dom APIs you'd use a higher level ODF api to query the 'file'.
> Just like a DOM tree you can just alter one or two properties and then
> write out the while file again without loosing data your app doesn't know
> about.

Yes, I think Robert Weir of IBM blogs about this a lot.

> At Akademies ODF-day this also came up and there were lots of people
> interrested in this idea. We even started an mailinglist [1], but since
> there was no code and not a clear idea on where to get that code from it
> stopped there.

I'll try to read through the archives over the next few days. Thanks for the 
pointer

> I am pretty sure that if you have a nice framework to hang this concept on,
> which allows you to alter the dept and broadness of the API using plugins
> etc it would be picked up and added to.

Well, this is more or less why I wrote "simple API" :)

Creating a "real" ODF API is really hard work since developers should be able 
to do a very wide range of tasks with it.

My assumption is that a rather simple and even limited API would be easier to 
design and implement and easier to use for a small range of use cases.

Eventually I can be re-implemented on top of a "full" ODF API, but I still 
think their goals are orthogonal.

However, since I have very little knowledge about ODF implications, it could 
be easier to go for the full API right away. You are certainly a lot more 
qualified to estimate the complexities of each approach, so if your opinion 
is that allowing limitations does not result in benefits for the design or 
implementation, it might be worth waiting for some different group to come up 
with "the real thing" and implement convenience on top of it.

> > I imagine a simple API being part of kdelibs for non-native data transfer
> > and using some KOffice library for "editing" real documents.
>
> KOffice applications all intend to use ODF as the dataformat for clipboard
> actions, and it would be great if you can then copy paste from KWord to
> KWrite without falling back to the plain-text part :)

I am specifically thinking about the use case of copying syntax highlighted 
source code into presentation slides and articles :)

> > The KOffice developers are most likely the ones who can give input on
> > this since they know the complexity involved with the full support and
> > can likely estimate if partial support would be easier to implement and
> > maintain.
>
> There are two parts to this;
> the first is to provide an API to simply get the text and get (some)
> markup. The second is to provide a way to convert from one document format
> to another. KOffice already has the second in a large part in its filters
> technology. There will be lots of interrest in the first, if only someone
> would start writing it :)

Can you give me some pointers, e.g. SVN directories, API docs links?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061229/8eb26eb8/attachment.sig>