incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [PROPOSAL] Combine ODFDOM and Simple API
Date Wed, 29 Feb 2012 22:35:06 GMT
On Thu, Feb 23, 2012 at 6:32 PM, Svante Schubert
<svante.schubert@gmail.com> wrote:
> On 23.02.2012 09:30, Devin Han wrote:
>> Hi all,
>>
>> As you know we will remove the deprecated ODFDOM DOC layer and replace it
>> with Simple API in the 2nd release. After that, ODFDOM will focus on low
>> level dom/package layer, while Simple API focus on the high level
>> convenient API. That would be a good news for users.
>>
>> Now, I have a new idea that why not combine ODFDOM and Simple API together?
>> If we do that, the advantages are:
>> (1) The user only needs to download a single jar. Include to classpath
>> easily and no need to care about the version dependency between ODFDOM and
>> Simple API.
> I would rather got the opposite way and split ODFDOM into a odfdom.jar
> and a odfpackage.jar to have a better modularization.
> The ODF specification comes along with a three parts. ODF XML, ODF
> formula and package for a reason. We should adapt the given modularity.
>

The spec has three parts because after 1000 pages it got too big for
us to efficiently edit in OpenOffice, and with a single person as
editor.  We needed to split up the work into different documents and
subcommittees.  It was classic "architecture follows organization".

Also, with the Simple API the intent is to be above the specification,
giving a view of the document that would be familiar to a user of a
word processor.  So their modular decomposition would differ from how
we wrote the ODF spec, which was targeting an editor implementer.

For example, in ODF tables are stored sparsely.  It is not a fully
instantiated matrix.  In particular, and similar to HTML, there are no
real table column in an ODF spreadsheet.  They are just something that
happens when you look at table cells that have the same cell offset in
a given row.  But to a spreadsheet user it is very natural to have
direct access to cell "B24" or to insert or delete a column. So we
support those as basic operations in the Simple API, even though they
do not correspond to simple concepts in ODF.

> Still we might and should ODFDOM and Simple API join to provide a single
> ZIP, as they belong semantically closer together as the other projects.
>

+1

> I do not see the download of multiple Jars as a problem.
> Users tend to use build tools as Maven automated the download the jar or
> download a jar only once. As mentioned we might even bundle jars to a
> zip for manual download, as for instance Apache Xerces does.


>> (2) ODFDOM and Simple API javadoc are together, user can find class, method
>> easily.
> Quite the opposite. Simple API is called simple as you do only have such
> a little powerful API calls, which bundle several DOM API calls.
> If combine them, you will have again a jungle of an API.
>

In practice we see users call into ODFDOM from the Simple API.  So
regardless of what we do with the JAR's it would be good to produce
some consolidated JavaDoc, so the developer can more easily navigate
between the API's.

> In addition Simple and ODFDOM are different views on the model, we
> should keep them separated.
> Currently I am trying to evolve ODF operations to be serialized for ODF
> change-tracking at OASIS.
> In the end it is very close to the Simple API and should be later be
> implemented as such, see
> http://www.oasis-open.org/committees/document.php?document_id=45161&wg_abbrev=office-collab
>
>> (3) People, who only use ODFDOM before, has a chance to use Simple API to
>> improve the efficiency. The jar of Simple API 0.7 is only 444.8 KB, would
>> not take too much space.
> I would indeed adapt our documentation / markering and put odfdom and
> simple documentation closer together. Allow the jars and API being
> downloaded as one, as they belong together.
>> The questions are:
>> (1) We need a new name for ODFDOM&Simple API.
>> (2) What's the new package name of Simple API?  Inherit ODFDOM DOC Layer
>> name or change nothing?
> Therefore a mixed answer:
> +1 for moving ODFDOM and Simple API closer together via wiki/website
> documentation, Maven subproject and download bundle (ZIP)
> -1 for moving ODFDOM and Simple API JavaDoc and JAR level together
>
> - Svante
>

Mime
View raw message