The OpenDocument XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only. For current information on ODF, please see the OASIS OpenDocument Technical Committee.

An OpenDocument Developers Kit (ODDK)

Forum topic: Submitted by rcweir on Thu, 2006-09-21 16:09. Last updated on Thu, 2006-09-21 16:11.

Parent post for discussions related to the proposal for an Open Document Developer's Kit (ODDK).

‹ libodf architecture Programming Support for OpenDocument ›
  • Login to post comments
  • 11746 reads

My thoughts regarding an OpenDocument toolkit

michael.brauer | Mon, 2006-09-25 17:21
Rob,

thank you for sharing your thoughts on an OpenDocument toolkit with us.
Please see my recent GullFOSS blog entry for my own thoughts on an OpenDocument toolkit.

Michael

Spreadsheet

jdavid.eisenberg | Fri, 2006-09-22 23:54
In your proposal, you say "provide a high-level model, closer to the problem domain of application developers, with objects which represent spreadsheets, cell and column formats."

The Jakarta POI project (http://jakarta.apache.org/) contains a description of a high-level spreadsheet format (http://jakarta.apache.org/poi/hssf/quick-guide.html).  This might be a good starting point.

functions to perform common task

ooi | Fri, 2006-09-22 14:58
I like the idea of pluggable serialization to different document formats.

I like bdarcus idea of a superset API.

As someone who use DOM Parser regularly, I am sometimes frustrated by the fact that at times I have to create individual elements. Hence, it may be useful to have functions to perform common task. Using HTML as an  example:

node.appendItalicText("my italic text")

will append "<i>my italic text</i>", rather  than having to create child node "i" and grand-child node textnode "my italic text" individually.

Best regards,
Cinly

Just to give a sense of the

bdarcus | Sat, 2006-09-23 17:49
Just to give a sense of the more forward-looking implications of my advocacy of a clean supset WRT to metadata, see this blog post of mine. I'd like to end up with methods (and in turn new UIs) that encourage more semantic content authoring, where "ItalicText" gets deprecated (not formally, mind you; I recognize legacy issues), and instead users can more easily say what they mean.

Time to reimagine just a bit what document authoring ought to look like in the 21st century.

Metadata approach is indeed

ooi | Mon, 2006-09-25 13:50
Metadata approach is indeed better. It separates content from presentation and make it easier for data-mining, something I really like to see in documents.

Worst case scenario is I start to use "italic", "bold" etc as metadata. In fact, this can be a way to deal with legacy document.

The big unknown I have with metadata is "Will users do it"? My worry is anything that requires user to do extra work, e.g., tagging metadata to text, is not going to be workable.

One good example of a rethink of document authoring ought to look like in 21st century is the winning entry of KOffice GUI and Functionality Design Competition (http://www.koffice.org/competition/gui1results.php). I like to see something like this in the proposed kit.

Best regards,
Cinly

Two things:1) On the "will

bdarcus | Mon, 2006-09-25 14:32
Two things:

  1. On the "will users do it?" question, I'd turn the question around and say "will application developers finally make it easy for users to do what they already want to do?" I think this is more a failure of imagination for GUI designers than it is something fundamental to document authoring or users.
  2. Worse case is, yeah, 1 doesn't really happen. But at least you design an API to not make it really difficult. Same with allowing lists to be inlcuded in paragraphs; you can't export it at as is to OXML or ODF now, but at least the logic is there.

I like the idea Rob. The

bdarcus | Thu, 2006-09-21 18:15
I like the idea Rob. The wide binding coverage is particularly important.

It would be nice, though, to not design an API and tools strictly from the ODF spec, but to perhaps consider a superset that removes some of the structural weakness that XHTML 1.0, ODF and OXML all share, but which other formats (DocBook, XHTML 2.0) do not.

A list or a blockquote, for example, should be able to be a part of a paragraph object, rather than to always necessarily stand alone.

Likewise, instead of fixed metadata properties tied only to the document, one might design it to be more flexible up front ;-)

true

rcweir | Thu, 2006-09-21 22:01
Hi Bruce,

Good point.  The trick is to find something that is intuitive to the application developer.  Replacing a 700-page XML specification with a 700-page API specification will not solve this problem.  If you assume that the app developer does not already know ODF, then what is the source of his or her intuition?  This would need to be their experience with using word processors and spreadsheets, as well as their experience using modern programming languages and XML API's.  I think we can assume those three as a common background and build upon the conceptual models that flow from that.

-Rob

Subscribe

Syndicate content
Currently online: 27 guests and 0 users:
XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I

Hosted by:

OASIS