ODF toolkit and Apache POI are both APIs to specific file formats. The key differences with DocFormats are
1. Support for multiple file formats (a limited range supported presently, but the intention is to expand to other formats) 2. Ability to "abstract over" a file format, in that the goal is to allow people to write apps without caring what format the data is physically stored in 3. Use of HTML as a common intermediate format during translation (though other formats can be manipulated if natively supported by an editor, then converted back to the source format) 4. Bi-directionality, i.e. the ability to do non-destructive updates when converting between formats 5. A building-block for creating HTML-based editors, viewers, and other applications (in particular, using WebKit or other browser engines) 6. No reliance on Java If you want to do mobile, you can't use anything Java-based - that is, if you want to support iOS. No-one can use the two projects you mentioned if they want to build an iPhone or iPad app, which is one of several reasons ODF is absent from the mobile space. Although in the past, Java has been a great choice for cross-platform applications, sadly this is no longer the case - hence C (the code was originally in Objective C but translated to C). It's also an extra dependency which can unnecessarily bloat requirements for an application, whereas this is very lightweight. In addition to a library for dealing with file formats, the overall idea is much wider than that - to build applications on top of this, such as an editor, also within the context of the project. And also, promoting the idea of "file format independence", in the same way as most now see platform-independence as a good thing. We're looking to make it as flexible as possible, so that it can be adapted for mobile, desktop, and web. It's sort of a "clean start" in a sense, though not necessarily aiming to entirely replicate existing projects, but rather something new. Both the ODF toolkit and Apache POI have useful work which will quite possibly be of use. In particular I think the latter may be helpful for supporting the older binary MS file formats, and we hope to collaborate with other Apache projects where relevant. -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) On 16 Aug 2014, at 11:38 pm, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > I don't have any skin in this game. > > Yet I am baffled about where this work is going on and what Apache Project it > relates to. Is there an incubator proposal for Apache DocFormats on its way? > > In particular, I would expect that some thought would be given to the ODF > Toolkit and that incubator project, <http://incubator.apache.org/odftoolkit/>. > > Also, Apache POI would seem to have some relevance, especially the OpenXML4J > component, <http://poi.apache.org/>. > > These are all Java based, as is Armin's current project in the AOO > repository. I haven't listed open-source projects outside the embrace of ASF. > > A single <orcnote> remark is in-line below (although this notation may derail > defective HTML presentation of plaintext containing angle brackets). > > Re-subscribing to general-incubator now ... > > Oh, and congratulations on joining the IPMC, Jan. > > -- Dennis E. Hamilton > dennis.hamil...@acm.org +1-206-779-9430 > https://keybase.io/orcmid PGP F96E 89FF D456 628A > X.509 certs used and requested for signed e-mail > > > > -----Original Message----- > From: jan i [mailto:j...@apache.org] > Sent: Saturday, August 16, 2014 01:10 > To: dev > Subject: Re: DocFormats - Open source OOXML implementation > > On 16 August 2014 03:50, Peter Kelly <kelly...@gmail.com> wrote: > > [ ... ] >> Now, onto the fix: >> >> The library needs to have some way of checking that the HTML file being >> used as part of an update operation has a mapping (id attributes) that >> match the docx file being updated (in the case of creating a new file, this >> is just an empty docx file). In the even that this is not the case, it >> could still do the update, but would act as if the entire document had been >> replaced with a completely new one. >> >> The solution I'll likely implement (and this should really be my first >> task, given the potential for problems like the above is this): >> > In my humble opinion you should not use time on this right now. > > If you fix a bug we have a 1-1 relation (1 man used, 1 bug fixed) > If you start getting the documentation right we have a 1-n relations (1 man > used, n men help fix bugs). > > Please have in mind, we build a community in order to move away from "I > have to do it, because I am the only one who know how" and you are the most > important enabler of that......we need your knowledge in a file, so that > others can work. > > [ ... ] > > When the project (hopefully) enters incubator, we will automatically have > access to a bug tracking system (jira), and with that hopefully only being > some month away I would not recommend setting up one now. > > <orcnote> > On Github, there is already an issues structure, > <https://github.com/uxproductivity/DocFormats/issues>. > I think this should be continued in use until a different > setup arrives "any day soon". Note that some Github projects > create a single subrepository that is just for its issues > function. E.g., https://github.com/keybase/keybase-issues > </orcnote> > > > [ ... ] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org >
signature.asc
Description: Message signed with OpenPGP using GPGMail
