Apache OpenOffice Wiki - User contributions [en]

Conferences/FOSDEM/2010

2010-02-02T14:49:39Z

Sus: /* Team */

{{DISPLAYTITLE:FOSDEM 2010}}

[http://www.fosdem.org/2010/ FOSDEM] 6-7 February 2010 in Brussels, Belgium

This page will collect ideas, todos and everything else that is related to the OpenOffice.org project activities @FOSDEM 2010. Planned activities are so far a stand to represent the OpenOffice.org project and to be the central info point for all OpenOffice.org related questions. And we want again organize a DevRoom to inform about our ongoing development work and projects. For more details please check the sections below.

==Communication Channel==
For all FOSDEM relevant communication the mailing list [http://marketing.openoffice.org/servlets/SummarizeList?listName=fosdem fosdem@marketing.openffcie.org] is used. If you are interested in any activities around FOSDEM please [http://marketing.openoffice.org/servlets/ProjectMailingListList subscribe] yourself. For special message or requests (like CFP) we will use some further mailing lists as well.

==DevRoom==
OpenOffice.org is accepted and we have a DevRoom for 1 day, on Saturday 6th February from 13:00 to 19:00. We will share our DevRoom with the ODF group which have no additional own DevRoom.

===Call for Papers===
The schedule for our DevRoom is organized by us and we can use the time as we want. We should plan with 45, 90 or 120 minutes sessions.

Some things that should be taken into account
* activity title (please try to be descriptive, there are ~250 talks at FOSDEM during the week-end ;)),
* a short abstract (1-2 paragraphs),
* a longer description if appropriate,
* optionally a list of links to the project website or similar
* for each speaker:
** the speaker's real name,
** a short overview of her bio in a couple of lines,
** optionally also a longer bio,
** optionally a picture (please send it to Juergen as 128x128 PNG),
** optionally links to her website, blog, ...

We have no guarantee so far but probably we can sponsor potential speakers with some funding to at least cover parts of the costs.

====Proposals====
Papers, talks, workshop proposals or something else that fits into the DevRoom should be proposed on the following wiki page [[Conferences/FOSDEM/2010/CFP|CFP]] until Friday 12/18/2009.

===Schedule===

Changes are still possible

{| border=1
|+ DevRoom Overview
|- bgcolor=#CDDBF6
| colspan="5" align="center" | '''[http://www.fosdem.org/2010/schedule/devrooms/openofficeorg OpenOffice.org DevRoom]''', Building AW, Room AW1.120
|- bgcolor=#CDDBF6
! Time !! Title !! Session type !! Slides !!Speaker
|- bgcolor=#7c9acd
| colspan="5" align="center" | '''OpenOffice.org'''
|-
| 13:00 - 13:45 || [[Conferences/FOSDEM/2010/CFP#Tips_and_Tricks_for_Extension_Developer|Welcome + Tips and Tricks for Extension Developer]] || talk || ? || [[User:Jsc|Juergen Schmidt]]
|-
| 13:45 - 14:30 || [[Conferences/FOSDEM/2010/CFP#New_docking_windows_for_a_better_UI_.26_extension_integration|New docking windows for a better UI & extension integration]] || talk || ? || Carsten Driesner
|-
| 14:30 - 15:15 || [[Conferences/FOSDEM/2010/CFP#Improving_the_OpenOffice.org_Build_System|Improving the OpenOffice.org Build System]] || talk || ? || Bjoern Michaelsen
|-
| 15:15 - 16:00 || [[Conferences/FOSDEM/2010/CFP#Just_Testing|Just Testing]] || talk || ? || Stephan Bergmann
|-
| 16:00 - 16:45 || [[Conferences/FOSDEM/2010/CFP#Show_me_YOUR_code|Show me YOUR code]] || workshop || ? || [[User:ErAck|Eike Rathke]]
|-
| 16:45 - 17:30 || [[Conferences/FOSDEM/2010/CFP#Hidden_Pearls_-_What.27s_There_to_ReUse_for_Other_Projects|Hidden Pearls - What's There to ReUse for Other Projects]] || talk || ? || Thorsten Behrens
|- bgcolor=#7c9acd
| colspan="5" align="center" | '''ODF'''
|-
| 17:30 - 18:00 || [[Conferences/FOSDEM/2010/CFP#ODF_Tools_and_Resources|ODF Tools and Resources]] || talk || ? || [http://be.linkedin.com/in/barthanssens Bart Hanssens]
|-
| 18:00 - 18:30 || [[Conferences/FOSDEM/2010/CFP#ODF_on_the_server_-_ODFDOM_architecture|ODF on the server - ODFDOM architecture]] || talk || ? || Svante Schubert
|-
| 18:30 - 19:00 || [[Conferences/FOSDEM/2010/CFP#lpOD_.E2.80.93_languages_.26_platforms_OpenDocument|lpOD – languages & platforms OpenDocument]] || talk || ? || Luis Belmar Letelier
|}

== Stand/Booth ==

Our stand will be most probably in building AW

{| border="1"
|+ Stand Overview
|- bgcolor="#cddbf6"
! Time
! Stand staff
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Saturday 6th'''
|-
| 10:00 - 12:00
| floeff, jsc, lmo, sb, sophi, b_michaelsen<br>
|-
| 12:00 - 14:00
| floeff, lmo, er, sophi, thb, jra<br>
|-
| 14:00 - 16:00
| floeff, cno, lmo, sophi, cd, jra<br>
|-
| 16:00 - 18:00
| floeff, jsc, cno, lmo, sophi, b_michaelsen<br>
|- bgcolor="#7c9acd"
| align="center" colspan="4" | '''Sunday 7th'''
|-
| 10:00 - 12:00
| probably floeff, jsc, sophi, b_michaelsen, thb<br>
|-
| 12:00 - 14:00
| jsc, cno, sb, sophi, cd, jra
|-
| 14:00 - 16:00
| cno, er, sophi, jra
|-
| 16:00 - 17:00
| cno, sophi, jra<br>
|}

=== Stand material ===
* sophi: I'll bring a coffee machine, tea and coffee, water, biscuits and cakes. Plugs, scissors, etc... A blue table coth. What else?
* jsc: i will bring 3 posters, stickers and t-shirts. All with the same design!

{| border=1 cellpadding="5" cellspacing="0"
|-
| [[Image:fosdem_design.png|thumb|left|150px|FOSDEM design]] || valign="top" | [[File:fosdem_design.pdf]] || valign="top" | design background:<br>- the squirl stands for a moving, rotating, active, vital community<br>- the cubes stand for the many, many individuals<br>- and the different colors stand for different countries, continents.
|}

==Saturday Evening OOo Community Event==
===Where===
'''[http://www.sensum.be/en/resto/show/l-achepot?Brussels L'Achepot]''' (Gourmet Bistro)

Place Sainte-Catherine, 1 - 1000 Brussels - Tel : +32 (0)2 511 62 21

Open from 12h to 14h30 and from 19h to 22h45.

===When===
8:00pm?

== Team ==

...details will coming soon

{| border="1"
|- bgcolor="#cddbf6"
! Name
! Stay
! Function
! Funding request
! Dinner on Saturday
|-
| Juergen Schmidt
| Friday - Sunday
| Stand/DevRoom
| 140 Euro hotel, ~150 Euro fuel
| yes
|-
| Florian Effenberger<br>
| Friday-Sunday
| Stand/Marketing
| 233 Euro flight, ~144 Euro hotel<br>
| yes
|-
| Cor Nouws [cno]<br>
| both days
| Stand/Marketing
| 70 Euro Hotel, 90 Euro train
| yes
|-
| Jacqueline Rahemipour
| both days
| Stand/Marketing<br>
| 120 Eur hotel, 90 Eur train
| yes
|-
| Eike Rathke
| both days
| Stand / DevRoom
| 140 Euro hotel, ~150 Euro fuel
| yes, 2 persons
|-
| Thorsten Behrens
| both days
| Stand / DevRoom
| 124 Euro hotel, 140 Euro airfare
| yes
|-
| Bjoern Michaelsen
| both days
| Stand / DevRoom
| 140 Euro hotel
| yes
|-
| Stephan Bergmann
| both days
| Stand / DevRoom
| 140 Euro hotel
| yes
|-
| Carsten Driesner
| both days
| Stand / DevRoom
| 140 Euro hotel, ~150 Euro fuel
| yes
|-
| Leo Moons
| Saturday
| Stand
| no
| yes
|-
| Sophie Gautier
| both days
| Stand
| no
| yes, 2 persons
|-
| Louis Suarez-Potts
| Friday-Sunday
| Stand
| Yes: flight & lodging
| Yes
|-
| Michael and Mechtilde
| Saturday-Sunday
| Stand / QA
|78 € + < 50 €
|
|-
| Oliver-Rainer Wittmann
| Friday-Sunday
|
|
| Yes
|-
| Svante Schubert
| Friday-Sunday
|
|
| Yes
|}

==Hotel Recommendation==
Brussels is a big city and especially during work days crowded with EU people. Here you can find three hotels that are all in the city directly and a perfect start point for the conference as well as night life activities. The prices are all for a single room.

* [http://www.astridhotel.be/ Hotel Astrid], price at the weekend 69 Euro or Cash&Sleep 59 Euro
* [http://www.arishotel.be/ Hotel Aris], price at the weekend 75 Euro or Cash&Sleep 65 Euro
* [http://www.almahotel.be/ Hotel Alma], price at the weekend 75 Euro or Cash&Sleep 65 Euro

Feel free to insert some more recommendations.

[[Category:Conferences]]
[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:26:22Z

Sus: /* ODF Tools and Resources */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| Talk / 30 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:SvanteSmiling.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:25:35Z

Sus: /* ODF Tools and Resources */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 30 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:SvanteSmiling.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:25:11Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:SvanteSmiling.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

File:SvanteSmiling.png

2010-01-08T16:23:22Z

Sus:

Conferences/FOSDEM/2010/CFP

2010-01-08T16:21:33Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:16:44Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
{{ns:Image}}
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:16:01Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| {{ns:File}}
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:10:12Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:http://profile.ak.fbcdn.net/v225/765/100/n1026825484_8952.jpg]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:08:53Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
| ODFDOM is the name of the free OpenDocument framework, which was recently published in version 0.75 to support ODF 1.2. Its overall purpose is to provide the ODF developer community a lightweight programming API in order to easily access and manipulate ODF documents. With its version 0.75, ODFDOM supports all ODF 1.2 elements and attributes, generated from the OpenDocument RelaxNG schema directly into the Java source code. The upcoming presentation will give an overview over the architecture, design ideas and in addition deliver insights about the roadmap and upcoming features.
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for details...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:06:57Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
|
|-
| Description
| See [http://odftoolkit.org/projects/odfdom/pages/Home http://odftoolkit.org/projects/odfdom/pages/Home] for detail...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:04:58Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|-
| Abstract (1-2 paragraphs)
|
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T16:03:51Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
Svante Schubert (Sun Microsystems Inc.) has been a full-time developer for OpenOffice.org since its foundation. On OpenOffice.org he is the co-lead of the 'XML project', with emphasis on XML based filters and the new RDF metadata model of the OpenDocument Format 1.2. On the 'ODF Toolkit project' he is responsible for the new ODFDOM library. He works on the ODF standardization in the OASIS ODF TC, the German DIN and ISO SC34.
|
|-
| Abstract (1-2 paragraphs)
|
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T15:59:11Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF on the server - ODFDOM architecture'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|
|-
| Abstract (1-2 paragraphs)
|
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010/CFP

2010-01-08T15:58:47Z

Sus: /* ODF on the server - ODFDOM architecture */

{{DISPLAYTITLE:Call for Papers for the OpenOffice.org and ODF DevRoom@FOSDEM 2010}}

<font size="6" color="red">Deadline: Friday, December 18th</font><br>

==Proposals==

===Local community building - Open-Source-Treffen===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | <span style="font-weight: bold;">Local community building - Open-Source-Treffen
</span>
|-
| Topic
| Local community building - Open-Source-Treffen
|-
| Session/duration
| ?? / ??
|-
| Speaker
| Florian Effenberger, OpenOffice.org<br>Carsten Book, Mozilla<br>
|-
| Biography
| Florian Effenberger has been an open source evangelist for many years. He is co-lead of the international OpenOffice.org marketing project as well as a member of the management board of the non-profit OpenOffice.org Deutschland e.V. He is also a frequent contributor to a variety of professional magazines worldwide.
|-
| Abstract (1-2 paragraphs)
| Mozilla and OpenOffice.org jointly organize so called open source meetings ("Open-Source-Treffen") in Germany to foster the idea of community building and to support exchange amongst projects and communities. This talk gives an overview of the idea, on what we achieved so far, what our plans for the future are - and how you can help!
|-
| Description
| Most people use open source software day by day. A fact that most of them do not know: Often, this free software is being developed, documented, marketed and improved by volunteers in their free time. Many open source projects work on fostering the idea of free software and open content, and a lot of users benefit from their efforts. Other than with proprietary software, users can get in direct touch with the communites via blogs, IRC channels, mailing lists or forums.
Despite the modern way of communicating, personal contact still is the best way to get to know each other. Meeting the people behind the names in reality is a great experience, and helps users of finding their way into open source communites to engage themselves. Therefore, Mozilla and OpenOffice.org jointly organize the so-called "Open-Source-Treffen" ("Open Source Meetings") to help open source projects in meeting their end-users and vice versa. Members of the community can get in touch with their users to gather valueable feedback, and open source adopters meet other supporters from their area.

In the German city of Munich, the "Open-Source-Treffen" have been taking place regularly, and the idea is to spread the word for other areas, engaging community members to set up more meetings. Carsten Book of Mozilla and Florian Effenberger of OpenOffice.org, founders of the "Open-Source-Treffen", introduce their vision and tell about the previous experiences. Audience for this talk are open source communities wishing to set up their own meetings as well as interested users who love to learn more about the idea.<br>

|-
| Additional speaker info
| [http://www.opensourcetreffen.de http://www.opensourcetreffen.de]
|-
| Speaker Photo (128x128 PNG)
| [[Image:Floeff.jpg]] See [[User:Floeff]]<br>
|}

=== ODF Tools and Resources ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''ODF Tools and Resources'''
|-
| Topic
| ODF
|-
| Session/duration
| Talk / 45 mins
|-
| Speaker
| Bart Hanssens
|-
| Biography
| Bart Hanssens is chairing the OASIS ODF Interop and Conformance TC, co-organizer of the ODF plugfests and has been testing various ODF applications for the Belgian Federal government in his role as Interoperability Expert at Fedict
|-
| Abstract (1-2 paragraphs)
| This session lists the various ODF tools and libraries that are "out there", and where one can find additional info about ODF itself.
|-
| Description
| ODF has become a popular document format, but for new developers it isn't always clear what open source tools exist and where to find them. This presentations aims to list the most interesting tools, libraries, projects and other resources available.
|-
| Additional speaker info
| http://be.linkedin.com/in/barthanssens
|-
| Speaker Photo (128x128 PNG)
| (See LinkedIn profile)
|}

===lpOD – languages & platforms OpenDocument===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''lpOD – languages & platforms OpenDocument'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| TALK / 30min
|-
| Speaker
| Luis Belmar-Letelier, Charles, JMG and/or Jérôme ?
|-
| Biography
| Luis Belmar-Letelier PhD in Physics, CEO of Itaapy a Python agil shop since 2003, work with the ODF Toolkit Union, and is the coordinator of the lpOD project http://lpod-project.org
|-
| Abstract (1-2 paragraphs)
| Presentation of the lpOD -- languages & platforms OpenDocument
|-
| Description
| lpOD, is a Free Software project that offers, for high level use cases, an application programming interface dedicated to document processing with the Python, Perl and Ruby languages. It’s complying with the Open Document Format (ODF).
|-
| Additional speaker info
| http://fr.linkedin.com/in/luisbelmarletelier
|-
| Speaker Photo (128x128 PNG)
|
|}
===ODF on the server - ODFDOM architecture ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenDocument format (ODF)
|-
| Session/duration
| talk / 30min
|-
| Speaker
| Svante Schubert
|-
| Biography
|
|-
| Abstract (1-2 paragraphs)
|
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:sus.png]]
|}

<br>

===Tips and Tricks for Extension Developer===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Tips and Tricks for Extension Developer'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Juergen Schmidt
|-
| Biography
| Juergen Schmidt is working for Sun Microsystems in the StarOffice group for more then 12 years. He was deeply involved in the development of the UNO component model which is the foundation for the OpenOffice.org API. The OpenOffice.org community is one aspect of his daily work. He is involved in the OpenOffice.org project since the beginning, he is the project lead of the OpenOffice.org API and the Extensions project and he is a member of the OpenOffice.org Community Council. His main goal is to spread the knowledge around the programmability features of OpenOffice.org around the world and to show that it is more than only an office productivity suite. He speaks frequently about the programmability features of OpenOffice.org on international conferences.
|-
| Abstract (1-2 paragraphs)
| The session will give an overview about the Extension infrastructure and will give tips and hints what's most important to integrate well in OpenOffice.org and to provide a more professional extension. Extensions provide often the necessary connector from OpenOffice.org to other software systems and the better they are integrated the better is the overall user experience and the interoperability.
|-
| Description
| is coming soon...
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [[Image:jsc.png]]
|}

<br>

=== New docking windows for a better UI & extension integration ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''New docking windows for a better UI & extension integration'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45
|-
| Speaker
| Carsten Driesner
|-
| Biography
| Carsten Driesner works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2000. He is the project lead of the framework project since 2006.
|-
| Abstract (1-2 paragraphs)
| The main goal of the framework project is to provide low-level functions (like loading/storing documents, generic UI, OLE, filter management) to the application modules. As the generic OpenOffice.org UI is mainly based on framework code many aspects of the Project Renaissance must be implement there. This presentation wants to provide an overview about our latest plans to provide new and powerful docking window functions.
The presentation is split up into four different parts:
1. The current state of docking window design
2. The new docking window design
3. How can extensions profit from the new design
4. Future outlook
|-
| Description
| coming soon...
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/Framework
|-
| Speaker Photo (128x128 PNG)
| ....
|}

<br/>

=== Improving the OpenOffice.org Build System ===
{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Improving the OpenOffice.org Build System'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk, 45 minutes
|-
| Speaker
| Bjoern Michaelsen
|-
| Biography
| Bjoern Michaelsen works for Sun Microsystems, Inc. and StarOffice/OpenOffice.org since 2008. He is the a member of the ongoing [[Build Environment Effort]] and a member of the Writer/Framework team at Sun.
|-
| Abstract (1-2 paragraphs)
| The [[Build Environment Effort]] is an ongoing effort to update various aspects of the OpenOffice.org build environment. Some of the aims of this effort require to rethink the basic architecture of how OpenOffice.org is build.
This talk with present the results so far and how we are planning to go on.
|-
| Description
| see http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu for details
|-
| Additional speaker info
|
* http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu
* http://blogs.sun.com/GullFOSS/entry/build_scalability1
* http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice (by Mathias Bauer)
* http://wiki.services.openoffice.org/wiki/Build_Environment_Effort

|-
| Speaker Photo (128x128 PNG)
| [[Image:bmichaelsen.png]]
|}

<br/>

=== Show me YOUR code ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Show me YOUR code'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| Workshop, 90-120 minutes
|-
| Speaker
| Eike Rathke
|-
| Biography
| Eike Rathke is a core developer and co-lead of the OpenOffice.org Calc spreadsheet application. <br> Working on the spreadsheet core engine, formula compiler and interpreter since 1994. Also working on the number parser/formatter and doing related i18n work. He works for Sun Microsystems.
|-
| Abstract (1-2 paragraphs)
| Show me the code YOU have written and want to be integrated. Talk about, identify and hopefully clear obstacles. Let's solve remaining problems together.
|-
| Description
| The last two FOSDEMs I gave an overview of the Calc spreadsheet interpreter core, and showed how to debug and profile the beast. This year it is time YOU show me YOUR code. Go into details. Discuss your solution. Ask questions. <br> If you would like to dive into your code at the workshop I'd appreciate if you made it available in advance so I can take a look. Send a mail to mailto:erack@sun.com?subject=FOSDEM%20code
|-
| Additional speaker info
| http://wiki.services.openoffice.org/wiki/User:ErAck
|-
| Speaker Photo
| [[Image:ErAck_128x128.png]]
|}

<br/>

=== Just Testing ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Just Testing'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk/45 minutes
|-
| Speaker
| Stephan Bergmann
|-
| Biography
| Stephan has been working on all kinds of aspects of OpenOffice.org for well over a decade now, as a member of the StarOffice/OpenOffice.org development team at Sun Hamburg.
|-
| Abstract (1-2 paragraphs)
| OpenOffice.org is too fat and too weird to let you simply apply your standard unit-testing-approach to writing correct code. Over the years, this has lead to the creation of a number of mechanisms within the OOo code base with which OOo developers can test the code they write and compile. Some of the mechanisms are, erm, creative, some are trivial. But what all the mechanisms have in common is that they all are brittle and all start to fail, in one way or another, sooner or later. Time to clean up. <br/> This talk will discuss where we intend to go, and probably tell a couple of anecdotes about where we came from.
|-
| Description
| -
|-
| Additional speaker info
| [http://blogs.sun.com/gullfoss http://blogs.sun.com/gullfoss]
|-
| Speaker Photo (128x128 PNG)
| [http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg http://archive.fosdem.org/2009/schedule/images/speaker-270-128x128.jpg]
|}

<br/>

=== Hidden Pearls - What's There to ReUse for Other Projects ===

{| border="1"
|- bgcolor="#7c9acd"
| align="center" colspan="2" | '''Hidden Pearls'''
|-
| Topic
| OpenOffice.org
|-
| Session/duration
| talk / 45 minutes
|-
| Speaker
| Thorsten Behrens
|-
| Biography
| Thorsten has been hacking on OpenOffice.org for many years.
|-
| Abstract (1-2 paragraphs)
| This session presents a few examples of uniquely useful code inside OOo, plus a way for other projects to mine those pearls.
|-
| Description
| This [http://blog.thebehrens.net/2008/09/29/ooo-non-vision/ rant] (except for the ranting) pretty much conveys the ideas I want to present here
|-
| Additional speaker info
| [http://blog.thebehrens.net]
|-
| Speaker Photo (128x128 PNG)
| [http://blog.thebehrens.net http://netsroth.110mb.com/wtf2.png]
|}

[[Category:FOSDEM]]

Conferences/FOSDEM/2010

2009-12-30T16:20:46Z

Sus: /* Schedule */

User:Sus

2009-09-10T16:58:38Z

Sus: /* Personal Information */

== Personal Information ==

{| border=1
| Abbreviation || sus
|-
|Full Name || Svante Schubert
|-
| Role || XML & ODFTOOLKIT co-lead, ODFDOM project chair, Member of OASIS ODF TC, OASIS OIC TC, OASIS ODF SC Metadata
|-
| Member of the project || since the early beginning and even before...
|-
| Location || Hamburg, GERMANY
|-
| Company || Sun Microsystems
|-
|Mail || [[Image:mailto.svante.schubert.png]]
|}

...

DomainDeveloper

2009-09-10T16:55:09Z

Sus: /* Developers */ (checkpoint save)

A mapping of names to OOo accounts.

Abbrev.:

* PL : Project Lead
* CL : Project Co-Lead
* CC : Community Council Member
* ESC : Engineering Steering Committee Member
* CVS : has write access to the OOo CVS repository

----

=== Developers ===

{| class="prettytable sortable"
|-
! Name || CVS || @openoffice.org || [[IRC Communication]] || Notes || Affiliation
|-
| [[User:Agerskov|Claus Agerskov]]|| || cs||Agerskov, cagerskov||PL Project Management Tool ([http://oopm.openoffice.org oopm])||AgerCon
|-
| Volker Ahrendt|| X || va||||||Sun Microsystems
|-
| Kai Ahrens|| X || ka || Kai_Ahrens ||PL Graphic Applications||Sun Microsystems
|-
| Rail Aliev || X || rail || rail || Ru and Tr NL Co-lead || Infra-Resource
|-
| Gene Anaya|| || ganaya||||||
|-
| [[User:JoostAndrae|Joost Andrae]]|| X || ja||ja_||CL qa, release testing en-US builds and releasing/uploading builds and releases||Sun Microsystems
|-
| [[User:ericb|Eric Bachard]] || X || ericb||ericb2|| PL Education, Mac OSX/Linux PPC port and vcl/impress hacker || [http://education.openoffice.org Education project], unaffiliated
|-
| Kai Backman|| || kaib ||KaiB||||
|-
| Sascha Ballach|| X || sab||||||
|-
| Jayant Balraj Madavi|| || jayant_madavi||aZEN_JM||Connectivity / Database||Novell, Inc.
|-
| Jörg Barfurth|| X || jb||JoergB||Configuration Util||Sun Microsystems
|-
| Omer Bar-or|| X || cremlae||cremlae||Mac porting||Google Summer of Code
|-
| Mathias Bauer|| X || mba||||PL Writer, CL Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Novell, Inc.
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stephan Bergmann|| X || sb||||CL UDK||Sun Microsystems
|-
| Andreas Bille|| X || abi||||||
|-
| Éric Bischoff|| X || ebischoff||ebischoff||KDE A/B driver||Bureau Cornavin
|-
| Nick Blievers|| X || nick||||IRIX||
|-
| Daniel Boelzle|| X || dbo||||UNO core/bridges/packages||Sun Microsystems
|-
| Oliver Bolte|| X || obo||||RE||Sun Microsystems
|-
| Rafaella Braconi|| || coni||Rafaella ||PL l10n, Globalization Program Manager||Sun Microsystems
|-
| Michael Brauer|| X || mib||||PL XML||Sun Microsystems
|-
| Oliver Braun|| X || obr||obr||System Integration/Accessibility Hacker||Sun Microsystems
|-
| Andreas Bregas|| X || ab||||StarBasic||Sun Microsystems
|-
| Jörg Brunsmann|| || jbrunsmann||||UDK||
|-
| Jörg Budischewski|| || jbu||PyUNO hacker||||
|-
| Peter Burow|| X || pb||plumbumm||UI||Sun Microsystems
|-
| Aidan Butler|| || aidan||||XML filters||
|-
| Giuseppe Castagno || X || beppec56 || beppec56_ or beppe_c || PDF output
|-
| [[User:ScottCarr|Scott Carr]] || X || kcarr||kcarr||PL Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
|Jian Hong Cheng || X || chengjh || || Writer || IBM Corp.
|-
| Xiuzhi Cheng|| X || xzcheng || xiuzhi|| ESC,Xml,ODF|| OOo community
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| [[User:jza|Alexandro Colorado]]|| X || jza || jza|| CL [[OOoES|ES]] ||
|-
| Michael Cziebalski|| || mci||||||
|-
| [[User:pdefilippis|Pierre de Filippis]]|| X || pdefilippis||aliscafo||Mac OSX native porting||
|-
| Yuri Dario || || ydario || Paperino || OS/2 Port || Serenity Systems intl
|-
| Andrew Dent|| X ||ace_dent||ace_dent||ui/custom_images||
|-
| Naren Devaiah|| || ||ndev||Performance||Intel Corporation
|-
| Nitin Dongre|| || ||nitin_BITS||||Novell, Inc.(intern)
|-
| Radek Doulik|| || radekdoulik||rodo_||Canvas hacker||Novell, Inc.
|-
| Carsten Driesner|| X || cd|| cd_oo ||PL Framework||Sun Microsystems
|-
| Herbert Duerr|| X || hdu||hdu_hh||GSL||Sun Microsystems
|-
| Oliver Wittmann|| X || od||Writer||||Sun Microsystems
|-
| [[User:bei|Bernd Eilers]]|| X || bei||rfc821||[[EIS]]||Sun Microsystems
|-
| René Engelhard|| X || rene||_rene_||config_office, Debian packager||Debian
|-
| [[User:Pereriksson|Per Eriksson]] || || pereriksson || || CL, MarCon Sweden ||
|-
|[[User:Jbfaure|Jean-Baptiste Faure]]||X||jbfaure||jbfaure ||PL FR native-lang project||
|-
| Hubert Figuière|| X || hub || hub || PPTX || Novell, Inc.
|-
| Claudio F Filho|| || filhocf||filhocf||Brazilian portuguese Localization||BrOffice.org
|-
| Andre Fischer|| X || af||||Impress||Sun Microsystems
|-
| Uwe Fischer || X || ufi || ufiooo || Application Help || Sun Microsystems
|-
| Ken Foskey|| || waratah||waratah||config_office/dmake man||slug.org.au
|-
| Duncan Foster|| || dfoster||||||
|-
| David Fraser|| || davidfraser||davidfraser||South African translations, multilingual builds||translate.org.za
|-
| [[User:Nf|Nils Fuhrmann]]|| || nf||SunNF||||Sun Microsystems
|-
| Martin Gallwey|| X || mtg||marty_||XML/Writer/packaging||
|-
| Pierre-Andre Galmes || || pagalmes || pagalmes || Chart2 ||StarXpert
|-
| Tony Galmiche|| X || tonygalmiche||||FR native-lang project||
|-
| Sunil Gandhi|| || ||tyro||||NOSIP
|-
|Zemin Gao || || gaozemin|| gaozm || Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sophie Gautier|| X || sgauti|| sophi || ||.
|-
| Vladimir Glazounov|| X || vg||||RE||Sun Microsystems
|-
| Laurent Godard || X || laurentgodard || lgodard || CC, PL Extensions, Fr Native-lang Project || inDesko/Nuxeo
|-
| Jody Goldberg|| X || jodygoldberg||jody||[[Calc]] spreadsheet-ness||
|-
| Dirk Grobler|| X || dg|||| ||Sun Microsystems
|-
| [[User:Sg|Steffen Grund]]|| X || sg|| || NetBeans Integration ||Sun Microsystems
|-
| Bettina Haberer|| || bh||||RFEOwner||Sun Microsystems
|-
| Bo Han || X || hanbo || hanbo || VBA Interop || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Ingrid Halama|| X || iha||||Chart||Sun Microsystems
|-
| Chris Halls|| X || haggai||haggai||Debian packager&misc. hacker||Credativ Ltd., Debian
|-
| Gregor Hartmann|| X || gh|| Lachs ||Testtool, gsicheck, buildbot||Sun Microsystems
|-
| Bustamam Harun|| || bustamam||||Malaysian stuff||
|-
| Kevin Hendricks|| X || khendricks||||PL Lingucomponent, PowerPC||
|-
| Con Hennessy|| || cphennessy||cph2 or cph_||hacker & former council person||OpenApp
|-
| Ivo Hinkelmann|| X || ihi||ivo||l10n tooling/general/RE||Sun Microsystems
|-
| Eric Hoch|| X || maveric||mav_eric||Mac Porting||
|-
| [[User:Lutz_Hoeger|Lutz Hoeger]]|| X || lh ||lutzh||||Sun Microsystems
|-
| Ilko Höpping|| X || ih||||||Sun Microsystems
|-
| Jan Holešovský|| X || kendy||kendy||KDE integration||Novell, Inc.
|-
| Martin Hollmichel|| X || mh||Ratte/Nesshof||PL External, Tools, Porting, CC||Sun Microsystems
|-
| Karl Hong|| X || khong||||i18n, CJK expert||
|-
| Matthias Huetsch|| X || mhu||||Performance/strategy, PL UCB, CC, ESC||Sun Microsystems
|-
| Michael Hönnig|| X || mi||||PL API||
|-
| [[User:icobgr|Hristo Hristov]] || || icobgr || icobgr || PL Bulgarian native-lang project ||
|-
| Sven Jacobi|| X || sj||||Escherwizard||Sun Microsystems
|-
| Jörg Jahnke|| || jj||||tooling||Sun Microsystems
|-
| Christian Jansen|| || cj ||||Menu and Toolbar?||Sun Microsystems
|-
| Ocke Janssen|| X || oj||Base||||Sun Microsystems
|-
| Pavel Janík|| X || pjanik||paveljanik||PL Czech native-lang project, CL l10n, CC, ESC, l10n builds||
|-
| Berry Jia|| X || berryjia||||||
|-
| Mingfei Jia || X || jiamingfei || || Lotus Smart Suite filter,MS Word encryption || IBM Corp.
|-
| Chuang Jiang || || jiangc || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sunil Amitkumar Janki || || sjanki || sjanki || GNU Linux mipsel porter ||
|-
| Pascal Junck|| || pjunck||||||
|-
| [[User:pj@openoffice.org|Peter Junge]]|| X || pj|| peter13j|| OOo community contact for my Chinese Employer, QA||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Christian Junker|| || Cyb||christianju||API||Trees For Life
|-
| Etsushi Kato || X || ekato || || Mac OS X Port || Independent
|-
| Hirano Kazunari|| || khirano||||Japanese||
|-
| Dhananjay Keskar|| X || dkeskar ||dkeskar||Performance,Buildbot,cat-herder||Intel Corporation
|-
| Robert Kinsella|| || rkinsella||||||Sun Microsystems
|-
| Volodymyr Khrystynych|| || volody||||XML Filter||
|-
| Matthias Klose|| || doko||doko||Ubuntu, gcc, python packager||Canonical, Inc.
|-
| Laszlo Kovacs|| || lkovacs||||Documentation||
|-
| Tobias Krause|| X || tkr||||ucb||Sun Microsystems
|-
| Martin Kretzschmar|| X || mkretzschmar||martink||Gnome / Debian||Student
|-
| Will Lachance|| || wlach||wlach_||Word Perfect File Filters||Net Integration Technologies, Inc.
|-
| Thomas Lange|| X || tl||tl13||||Sun Microsystems
|-
| Lars Langhans|| X || lla||||||Sun Microsystems
|-
| Hans-Joachim Lankenau|| X || hjs||ause||dmake makefile expert, RE||Sun Microsystems
|-
| Németh László|| X || nemeth||||PL lingucomponent||
|-
| Jakob Lechner|| X || jakob_lechner||||Writer||Fabalabs
|-
| Michael Leibowitz|| X || mikeleib ||mikeleib||performance||Intel Corporation
|-
|Jian Li || || lijian || lijian|| Writer|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Wind Li|| X || windly||||Address books||
|-
| Xing Li || X || lixxing || || Accessibility || IBM Corp.
|-
|Weike Liang || || liangweike || liangweike || Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Ping Liao|| || pliao||||||
|-
| Tor Lillqvist|| X || tml||tml_||||Novell, Inc.
|-
| Fong Lin || X || pflin || Fong || VBA Interop, Scripting, CJK Enhancement || Novell, Inc.
|-
| Joachim Lingner|| X || jl||||Java, CLI||Sun Microsystems
|-
| Christian Lippka|| X || cl || cl ||Graphic Applications||Sun Microsystems
|-
|Jianli Liu || || liujl|| liujianli || Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Mindy Liu|| || mindyliu||||||
|-
|[[User:liutao |Liu Tao ]] || X || liutao || liutao ||PL modularization ,PyUNO, Async dialogs,|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| YiSong Liu|| || Liu YiSong || Liu YiSong|| PYUNO || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|YU Liu || X || ch2000liuy || LiuYU || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yuhua Liu || || liuyuhua|| yuhua|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| [[User:Dl|Dieter Loeschky]]|| X || dl ||||PL: ODF Toolkit||Sun Microsystems
|-
| [[User:fl|Frank Loehmann]]|| X || fl ||frankl||PL [http://ux.openoffice.org User Experience]||Sun Microsystems
|-
| Philipp Lohmann|| X || pl||PhilippL||VCL/X11 (GSL) hacker||Sun Microsystems
|-
| Michel Loiseleur|| || mloiseleur|| coren`|| Bugfixes ||Linagora
|-
| Jackson Low|| X || xxjack12xx||||Porting||
|-
| Patrick Luby|| || pluby||||Mac||
|-
|Jingrong Luo || || Luo Jingrong|| Luo Jingrong|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Prasad Madhav || X || pmadhav || pmadhav || Buildbot || Intern@Intel
|-
| Babak Mahbod|| || bmahbod||||||
|-
| Martin Maher|| || mmaher||||Writer & Filter chap||
|-
| Nakata Maho|| X || maho||_maho_||PL QA, PL JA, FreeBSD guy||Independent
|-
|Yonggang Mao || X || maoyonggang|| maoyg|| Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yue Lv || || lvyue || lvyue || Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
|-|
| Shane M Mathews|| X || smmathews|| smmathews ||[[Impress:_OpenGL_rendered_transitions]]||student
|-
| Frank Mau|| X || fma||||tooling||Sun Microsystems
|-
| [[User:smsm1|Shaun McDonald]] || X || smsm1 || shaunmcdonald || Mac Port, buildbot MacPort1 || Graduate
|-
| Caolán McNamara|| X || cmc||caolan||CL Writer & Filter man|| [http://www.redhat.com Red Hat Inc.]
|-
| Michael Meeks|| X || mmeeks||michael_||ugly hack-er, ESC||Novell, Inc.
|-
| Frank Meies|| X || fme||||Writer||Sun Microsystems
|-
| Federico Mena-Quintero|| || federicomena||federico||perfectionist||Novell, Inc.
|-
| Ismael Merzaq|| X || isma87||ismael_||Mac OSX native porting||Student
|-
| Michael Mi|| || mmi||||||
|-
| Björn Michaelsen|| X || b_michaelsen ||b_michaelsen|| Writer, Bookmarks, Performance, User Feedback Program ||Sun Microsystems
|-
| Björn Milcke|| X || bm||bm_||Chart||Sun Microsystems
|-
| Petr Mladek|| || pmladek||pmladek||SUSE RPMs, ooo-build releases||Novell, Inc.
|-
| Cyrille Moureaux|| X || cyrillem||Cyrille||||
|-
| [[User:Mmp|Matthias Müller-Prove]]|| X || mmp|| mprove|| [[User Experience]] || Sun Microsystems
|-
| [[User:Bluedwarf|Takashi Nakamoto]]|| || bluedwarf|| || Japanese || Student
|-
| Jan Navrátil || X || jnavrati || jnavrati || || [http://www.redhat.com Red Hat Inc.]
|-
| Niklas Nebel|| X || nn||||PL [[Calc]]||Sun Microsystems
|-
| Christoph Neumann|| X || cn||||[[UnoApiTest]]||Sun Microsystems
|-
| Frank Neumann|| X || fne||||MacPort||
|-
| NicelKM|| X || mnicel||nicel||||Novell, Inc.
|-
| Jan Nieuwenhuizen|| X || jcn||janneke||Layout code, hacker ||Novell, Inc.
|-
| [[User:ChristophNoack|Christoph Noack]]|| X || christophnoack ||christoph_n||CL [http://ux.openoffice.org User Experience]||
|-
| Bertram Nolte|| || bnolte||||||
|-
| Tomas O'Connor|| || toconnor||||Scripting Framework||
|-
| Maximilian Odendahl|| X || mod||mod||[[Notes2]] [[SQL_Syntax_Highlighting]]|| Student / SEPT-Solutions
|-
| Takashi Ono || X || tono || || MinGW port || Independent
|-
| Lars Oppermann|| X || lo||||||
|-
| Rakesh Pandit || X || rakeshpandit|| chacha_chaudhry|| Education Project - Starmath/fix module warnings|| Education Project
|-
| Rodrigo Parra Novo|| X || rodarvus||rodarvus||Gnumeric/Abiword OpenDocument Format support and port to Maemo||INdT (Instituto Nokia de Tecnologia)
|-
| Pierre Pasteau|| X || pastea_p || pierrep|| Education Project, SeaMonkey migration || Education Project
|-
| Edward Peterlin|| X || OPENSTEP||||Mac||
|-
| [[User:Fpe|Frank Peters]]|| X || fpe||||CL Documentation||Sun Microsystems
|-
| Christof Pintaske|| X || cp||||||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Sebastien Plisson|| X || plipli||plipli||Developer on Aqua port||OO Aqua Port
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality||Sun Microsystems
|-
| Jonathan Pryor|| || jpryor || jonp || || Novell, Inc.
|-
| Canghua Qu|| || quch || Canghua || AutoTest, Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Volker Quetschke|| X || vq||vq||W32-tcsh/bash build environment and dmake Hacker, ESC||Gravity Waves
|-
| Tino Rachui|| X || tra||tinor||GSL/Unix Hacker||Sun Microsystems
|-
| Goran Rakić || X ||goranrakic || || Serbian Native-Lang PL ||
|-
| [[User:Kr|Kay Ramme]]|| X || kr||||PL UDK||Sun Microsystems
|-
| [[User:ErAck|Eike Rathke]]|| X || er||erAck||CL [[Calc]], engine; CL i18n; stricken with number formatter||Sun Microsystems
|-
| Michael Rauch|| X || mrauch||||NetBSD||
|-
| Jens-Heiner Rechtien|| X || hr||blauwal||RE; OOo SCM (CVS, CWS tooling); Porting; Compilers||Sun Microsystems
|-
| Daniel Rentz|| X || dr|| drr ||[[Calc]] Excel filter, UI||Sun Microsystems
|-
| Florian Reuter|| X || flr||||Writer filters||Novell, Inc.
|-
| Georg Richter|| X || grichter||georg||Base, native MySQL driver||MySQL AB
|-
| G. Roderick Singleton|| || grsingleton||grsingleton||Documentation||pathtech.org
|-
| Hennes Rohling|| X || hro||||GSL & Util||Sun Microsystems
|-
| Bibek Sahu|| || Bibek||bibek||Impress pieces||Trees For Life
|-
| Andreas Schlüns|| X || as||||Framework||Sun Microsystems
|-
| Ingo Schmidt|| X || is||||(Native) Installation||Sun Microsystems
|-
| [[User:Jsc|Jürgen Schmidt]]|| X || jsc||jsc||PL API, CL Extensions, UNO, SDK||Sun Microsystems
|-
| [[User:Schmidtm|Matthias Schmidt]] || || schmidtm || schmidtm || Mac OSX Aqua Port || Sun Microsystems
|-
| Stephan Schäfer|| X || ssa||ssa||VCL||Sun Microsystems
|-
| Frank Schönheit|| X || fs||FrankS||Database Access, Forms||Sun Microsystems
|-
| [[User:Sus|Svante Schubert]]|| X || sus||Svante||XML & ODFTOOLKIT co-lead, ODFDOM project chair, Member of OASIS ODF TC, OASIS OIC TC, OASIS ODF SC Metadata||Sun Microsystems
|-
| [[User:Sts|Stella Schulze]]|| X || sts||||[http://ui.openoffice.org/nonav/VisualDesign/ Visual Design]||Sun Microsystems
|-
| Julian Seward || || sewardj || || valgrind ||
|-
| Darragh Sherwin|| || dsherwin||darragh||E-Legislation / E-GovSystems||Propylon
|-
| Wei Guo SHI || X || shiwg || || Accessibility and Smart Suite filter || IBM Corp.
|-
|[[User:Robertzhou | RobertZhou]]|| || robertzhou|| shizhoubo|| [[Framework]] ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Raul Siddhartha|| || rsiddhartha||raul||GTK File Selector||Novell, Inc.
|-
| Sarah Smith|| || ssmith||||||
|-
| [[User:mox|Mox Soini]] || X || mox || Moxed || Mac Porting ||
|-
| Rajesh Sola|| || rajeshsola||sola||misc.||NOSIP
|-
| Kai Sommerfeld|| X || kso||||manager & hacker||Sun Microsystems
|-
| Oliver Specht|| X || os||||PL UI||Sun Microsystems
|-
| Jörg Spindler|| || jspindler||||||
|-
| [[User:Rescue|Joey Stanford]] || || Rescue/k0fcc || Rinchen || CL [http://eo.openoffice.org/ Esperanto native-lang project] || [http://canonical.com Canonical] ||
|-
| Fridrich Štrba|| X || fridrich_strba||Fridrich||Word Perfect Hacker||Novell, Inc.
|-
| Keith Stribley|| X || kstribley||||Graphite fonts, Myanmar l10n||
|-
| [[User:Muthusuba|Muthu Subramanian]]|| X || muthusuba||muthusuba||misc.||
|-
| Louis Suárez-Potts|| || louis||louis||Community Manager||Collab.net
|-
|Quanfa Tang || || tqfa|| tangquanfa|| Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| David Tardon || X || dtardon || dtardon || || [http://www.redhat.com Red Hat Inc.]
|-
| Stefan Taxhet|| X || st||stx12||CC, interpersonal problem fixer||Sun Microsystems
|-
| Armin Theissen|| || armin||||||
|-
| Caio Tiago Oliveira|| X || asrail||asrail||CL QA, release testing pt-BR builds||BrOffice.org
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt|| rtimm ||RE||Sun Microsystems
|-
| [[User:mt|Malte Timmermann]]|| X || mt|| Malte || Accessibility, Security, Performance||Sun Microsystems
|-
| Gerhard Tonn|| || tonn||||s390||
|-
| Willem van Dorp|| || willem.vandorp||||||
|-
| Tom Verbeek|| X || tv|||| ||
|-
| Sander Vesik|| || svesik||||||
|-
| Daniel Vogelheim|| X || dvo||||XML||
|-
| Mikhail Voitenko|| X || mav||mav||Framework||Sun Microsystems
|-
| Robert Vojta|| X || rvojta||rvojta||Mac OS X related issue||
|-
| Dirk Völzke|| X || dv||||Installation||Sun Microsystems
|-
| [[User:Sparcmoz|Jim Watson]]|| X || sparcmoz|| sparcmoz||GNU Linux sparc porter||clug.org.au
|-
| [[User:Weiz |Zhao Wei ]] || || weiz || weiz || Chart2 || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Armin Weiss|| X || aw||||||Sun Microsystems
|-
| Gerd Weiss|| X || gm||||RE||Sun Microsystems
|-
| Dan Williams|| X || fa||dcbw||Mac et. al. hacker|| [http://www.redhat.com Red Hat Inc.]
|-
|[[User:wuy|Yan Wu]] || X || wuy || ||Framework || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Stephan Wunderlich|| X || sw||||||
|-
| Antonio Xu|| X || antoxu || antoxu || Async dialogs, PRC improvements || Intel Corporation
|-
|Dehua Xu || || xudehua || xudh || Release || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Steve Yin || X || steve_yin || steve_yin || Microsoft Office file format, PDF, Accessibility, ODF || IBM Corp.
|-
| Kohei Yoshida|| X || kohei||kohei_||[[Calc]] hacker, Calc optimization solver developer||Novell, Inc.
|-
| Guoqiang Yu|| X || yugq || yugq|| Performance || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Xiaoyang Yu|| || || ||Disk block reordering||Intel Corporation
|-
| George Zahopoulos|| X || georgez||||||
|-
| Kurt Zenker|| X || kz||smoketester||RE||Sun Microsystems
|-
|[[User:Zhangxiaofei|Xiaofei Zhang]]|| || Zhangxiaofei || zhangxiaofei/FelixZ || [[Framework]] ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Jianwei Zhao || || zhaojianwei || zhaojianwei || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Jeremy Zheng|| X || zhiming || Jeremy || Async dialogs, PRC improvements || Intel Corporation
|-
|[[User:majun|Jun Ma]]|| ||majun || || writer || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name ||CVS||@openoffice.org || [[IRC Communication]] || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||||sba||||writer||||Sun Microsystems
|-
| Thorsten Bosbach||X||tbo||||framework, testautomation||framework test automation||Sun Microsystems
|-
| Oliver Craemer||X||oc||||[[Calc]], testautomation||calc test automation||Sun Microsystems
|-
| Helge Delfs||X||hde||||testautomation, writer||Test automation||Sun Microsystems
|-
| Fredrik Haegg||X||fha||||writer, testautomation||Writer test automation||
|-
| Hasan Ilter||||hi||||writer, printing, pdf export||||Sun Microsystems
|-
| Michael Rüß||||mru||||writer, word im/export||||Sun Microsystems
|-
| Éric Savary||||es||||writer, accessibility||||Sun Microsystems
|-
| [[User:jsi|Joerg Sievers]]||X||jsi||jsi_sun||chart, xml, testautomation||Chart2, XML test automation||Sun Microsystems
|-
| Joerg Skottke||X||jsk||skotti||framework, qa/qatesttool||Framework test automation||Sun Microsystems
|-
| Marc Neumann||X||msc||||database, testautomation||Database access test automation||Sun Microsystems
|-
| Chris Lukasiak||||clu||||database||||Sun Microsystems
|-
| Frank Stecher||||fst||||[[Calc]]||||Sun Microsystems
|-
| Jack Warchold|||| jw||||writer, import/export filters||||
|-
| Uwe Luebbers||||ul||||framework||||Sun Microsystems
|-
| Thorsten Martens||||tm||||framework||||Sun Microsystems
|-
| Olaf Felka|||| of||of_sun||framework, installation||||Sun Microsystems
|-
| Thomas Klarhoefer||||kla||||chart||||Sun Microsystems
|-
| Wolfram Garten||X|| wg||||draw, impress||draw, impress test automation||Sun Microsystems
|-
| Christian Guenther||||cgu||||draw, impress||||Sun Microsystems
|-
| Ulf Stroehler|| || us||||||Sun Microsystems
|-
| [[User:Thorsten_Ziehm|Thorsten Ziehm]]||||| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

== Related Pages ==
* [[Commit Rights]]
* [[Contributing Patches]]
* [[User_Experience/Community|User Experience Team]]
* A map of OOo developers around the world is available at http://www.frappr.com/ooodev, please add yourself to the map if you're involved in OOo development. It's just fun to see who's where :-)

[[Category:Development]]

ODF Toolkit/Minutes/2009 01

2009-01-16T08:55:45Z

Sus: New page: = 2009/01/16 = {| class="prettytable" | | <div align="right">'''''<nowiki><Svante></nowiki>'''''</div> | '''''AGENDA:''''' |- | | <div align="right">'''''<nowiki><Svante></nowiki>'''''...

= 2009/01/16 =
{| class="prettytable"
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''AGENDA:'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1 Status of the Teams'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''2 Open discussions '''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''no news'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''I'll submit the last code version to review next week, though It is still not all-sided.and then I want to work for Removing Warnings from Java build. Can I work for this task,svante?'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Yes! Of course... That would be great!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''OK.Thanks.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''I am working on a CWS including fixes and as well try to find with Lars a better way for the community to participate...'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Nothing more from myside..'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''2 Open discussions '''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Anything for today, you would like to discuss?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''I haven't find the "Styles and Formatting" defination for controls in the new odf-v1.2?Maybe I haven,t find it?'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''You mean in the specification?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''yes'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''There is a new draft 13 available, I have not looked into it, but you might sent the TC (or the editor) a comment'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''en, then I'll discuss it with majun.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''ok'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Yes, that's a good idea. The section might have been renamed.. '''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''One last point from my side'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''ok.maybe it will be later,majun is on vacation.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''ok'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Most likely from next week on, Lars will take over the meeting for the next two months, as I will be in parental absence.. ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''ok:)'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Nothing else from my side, anything else from somebody?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''nothing from me.'''''

|-
|
| <div align="right">'''<nowiki>|<--</nowiki>'''</div>
| '''''bei has left freenode ()'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Than have a nice week-end!'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''byebye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''byebye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''bye :)'''''

|}

= 2009/01/09 =
{| class="prettytable"
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Morning'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/xiuzhi,isnick xiuzhi]>'''''</div>
| '''''Hi all'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/xiuzhi,isnick xiuzhi]>'''''</div>
| '''''happy new year'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''good morning'''''

|-
|
| <div align="right">'''''>[irc://freenode/NickServ,isnick NickServ]<nowiki><</nowiki>'''''</div>
| '''''identify svante4ever'''''

|-
|
| <div align="right">'''''<nowiki>*</nowiki>[irc://freenode/NickServ,isnick NickServ]<nowiki>*</nowiki>'''''</div>
| '''''You are now identified for Svante.'''''

|-
|
| <div align="right">'''<nowiki>===</nowiki>'''</div>
| '''''Svante n=chatzill p4FDDF1A4.dip.t-dialin.net You are now logged in. (id Svante, username n=chatzill, hostname p4FDDF1A4.dip.t-dialin.net)'''''

|-
|
| <div align="right">'''<nowiki>=-=</nowiki>'''</div>
| '''''User mode for Svante is now +e'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Same to you, xiuzhi!'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Let's start..'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''AGENDA:'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1 Status of the Teams'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''2 Open discussions '''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''no news'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''no progress form me,'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Same here. I am working on a patch, but did not make if for today, I got some merging problems.. Next week..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''duyunfen is on holiday, i don't know what about her'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/xiuzhi,isnick xiuzhi]>'''''</div>
| '''''MaJun: do you phone duyunfen?'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Christian and duyunfen are not here, therefore it was a quick agenda ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''yes,but did not ...'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''2 Open discussions '''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Anything you would like to discuss now?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Chinese Spring Festival is coming'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Cool! :-)'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''We should go back to China, Lars!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Welcome!!'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''When is the new Year in China starting, MaJun?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''25, January'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Still enough time to travel, Lars.. ;-)'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''Anyway until than we have to work a little further on...'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''See you next week, guys!'''''

|-
|
| <div align="right">'''''<nowiki><Svante></nowiki>'''''</div>
| '''''byebye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''byebye!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''bye :)'''''

|}

DomainDeveloper

2009-01-13T18:54:41Z

Sus:

A mapping of names to OOo accounts.

Abbrev.:

* PL : Project Lead
* CL : Project Co-Lead
* CC : Community Council Member
* ESC : Engineering Steering Committee Member
* CVS : has write access to the OOo CVS repository

----

=== Developers ===

{| class="prettytable sortable"
|-
! Name || CVS || @openoffice.org || [[IRC Communication]] || Notes || Affiliation
|-
| Volker Ahrendt|| X || va||||||Sun Microsystems
|-
| Kai Ahrens|| X || ka || Kai_Ahrens ||PL Graphic Applications||Sun Microsystems
|-
| Gene Anaya|| || ganaya||||||
|-
| Joost Andrae|| X || ja||ja||CL qa, release testing en-US builds and releasing builds||Sun Microsystems
|-
| Eric Bachard|| X || ericb||ericb2|| CL Education, Mac OSX/Linux PPC port ||Education project
|-
| Kai Backman|| || kaib ||KaiB||||
|-
| Sascha Ballach|| X || sab||||||
|-
| Jayant Balraj Madavi|| || jayant_madavi||aZEN_JM||Connectivity / Database||Novell, Inc.
|-
| Jörg Barfurth|| X || jb||JoergB||Configuration Util||Sun Microsystems
|-
| Omer Bar-or|| X || cremlae||cremlae||Mac porting||Google Summer of Code
|-
| Mathias Bauer|| X || mba||||PL Writer, CL Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Novell, Inc.
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stephan Bergmann|| X || sb||||CL UDK||Sun Microsystems
|-
| Andreas Bille|| X || abi||||||Sun Microsystems
|-
| Éric Bischoff|| X || ebischoff||ebischoff||KDE A/B driver||Bureau Cornavin
|-
| Nick Blievers|| X || nick||||IRIX||
|-
| Daniel Boelzle|| X || dbo||||UNO core/bridges/packages||Sun Microsystems
|-
| Oliver Bolte|| X || obo||||RE||Sun Microsystems
|-
| Rafaella Braconi|| || coni||Rafaella ||PL l10n, Globalization Program Manager||Sun Microsystems
|-
| Michael Brauer|| X || mib||||PL XML||Sun Microsystems
|-
| Oliver Braun|| X || obr||obr||System Integration/Accessibility Hacker||Sun Microsystems
|-
| Andreas Bregas|| X || ab||||StarBasic||Sun Microsystems
|-
| Jörg Brunsmann|| || jbrunsmann||||UDK||
|-
| Jörg Budischewski|| || jbu||PyUNO hacker||||Sun Microsystems
|-
| Peter Burow|| X || pb||plumbumm||UI||Sun Microsystems
|-
| Aidan Butler|| || aidan||||XML filters||
|-
| Giuseppe Castagno || X || beppec56 || beppec56_ or beppe_c || PDF output
|-
| [[User:ScottCarr|Scott Carr]] || X || kcarr||kcarr||PL Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
| Jinhong Chen || || chainchen || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Xiuzhi Cheng|| X || xzcheng || xiuzhi|| ESC,Xml,ODF|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| Michael Cziebalski|| || mci||||||
|-
| [[User:pdefilippis|Pierre de Filippis]]|| X || pdefilippis||aliscafo||Mac OSX native porting||
|-
| Andrew Dent|| X ||ace_dent||ace_dent||ui/custom_images||
|-
| Naren Devaiah|| || ||ndev||Performance||Intel Corporation
|-
| Quangang Dong|| || donqg || dongqg || Layout || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Nitin Dongre|| || ||nitin_BITS||||Novell, Inc.(intern)
|-
| Radek Doulik|| || radekdoulik||rodo_||Canvas hacker||Novell, Inc.
|-
| Carsten Driesner|| X || cd|| cd_oo ||PL Framework||Sun Microsystems
|-
| Yunfen Du || X || duyunfen|| dyf|| Base ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-

| Herbert Duerr|| X || hdu||hdu_hh||GSL||Sun Microsystems
|-
| Oliver Düsterhoff|| X || od||Writer||||Sun Microsystems
|-
| [[User:bei|Bernd Eilers]]|| X || bei||rfc821||[[EIS]]||Sun Microsystems
|-
| René Engelhard|| X || rene||_rene_||config_office, Debian packager||Debian
|-
| [[User:Pereriksson|Per Eriksson]] || || pereriksson || || CL, MarCon Sweden ||
|-
| Yaqiong Fang || X || fangyq || fangyq|| Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Hubert Figuière|| X || hub || hub || PPTX || Novell, Inc.
|-
| Andre Fischer|| X || af||||Impress||Sun Microsystems
|-
| Uwe Fischer || X || ufi || ufiooo || Application Help || Sun Microsystems
|-
| Ken Foskey|| || waratah||waratah||config_office/dmake man||slug.org.au
|-
| Duncan Foster|| || dfoster||||||
|-
| David Fraser|| || davidfraser||davidfraser||South African translations, multilingual builds||translate.org.za
|-
| [[User:Nf|Nils Fuhrmann]]|| || nf||SunNF||||Sun Microsystems
|-
| Martin Gallwey|| X || mtg||marty_||XML/Writer/packaging||
|-
| Pierre-Andre Galmes || || pagalmes || pagalmes || Chart2 ||StarXpert
|-
| Tony Galmiche|| X || tonygalmiche||||CL FR native-lang project||
|-
| Sunil Gandhi|| || ||tyro||||NOSIP
|-
| Peng Gao || || Gao Peng|| Gao Peng || writer|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Zemin Gao || || gaozemin|| gaozm || Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sophie Gautier|| X || sgauti|| sophi || ||.
|-
| Vladimir Glazounov|| X || vg||||RE||Sun Microsystems
|-
| Laurent Godard || X || laurentgodard || lgodard || CC, PL Extensions, Fr Native-lang Project || inDesko/Nuxeo
|-
| Jody Goldberg|| X || jodygoldberg||jody||[[Calc]] spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||Sun Microsystems
|-
| [[User:Sg|Steffen Grund]]|| X || sg|| || NetBeans Integration ||Sun Microsystems
|-
| Bettina Haberer|| || bh||||RFEOwner||Sun Microsystems
|-
| Ingrid Halama|| X || iha||||Chart||Sun Microsystems
|-
| Chris Halls|| X || haggai||haggai||Debian packager&misc. hacker||Credativ Ltd., Debian
|-
| Gregor Hartmann|| X || gh|| Lachs ||Testtool, gsicheck, buildbot||Sun Microsystems
|-
| Bustamam Harun|| || bustamam||||Malaysian stuff||
|-
| Kevin Hendricks|| X || khendricks||||PL Lingucomponent, PowerPC||
|-
| Con Hennessy|| || cphennessy||cph2 or cph_||hacker & former council person||OpenApp
|-
| Ivo Hinkelmann|| X || ihi||ivo||l10n tooling/general/RE||Sun Microsystems
|-
| Eric Hoch|| X || maveric||mav_eric||Mac Porting||
|-
| [[User:Lutz_Hoeger|Lutz Hoeger]]|| X || lh ||lutzh||||Sun Microsystems
|-
| Ilko Höpping|| X || ih||||||Sun Microsystems
|-
| Jan Holešovský|| X || kendy||kendy||KDE integration||Novell, Inc.
|-
| Martin Hollmichel|| X || mh||Ratte/Nesshof||Build Maestro, PL External, Tools, Porting, CC||Sun Microsystems
|-
| Karl Hong|| X || khong||||i18n, CJK expert||Sun Microsystems
|-
| Matthias Huetsch|| X || mhu||||Performance/strategy, PL UCB, CC, ESC||Sun Microsystems
|-
| Michael Hönnig|| X || mi||||PL API||
|-
| [[User:icobgr|Hristo Hristov]] || || icobgr || icobgr || PL Bulgarian native-lang project ||
|-
| Sven Jacobi|| X || sj||||Escherwizard||Sun Microsystems
|-
| Jörg Jahnke|| || jj||||tooling||Sun Microsystems
|-
| Christian Jansen|| || cj ||||Menu and Toolbar?||Sun Microsystems
|-
| Ocke Janssen|| X || oj||Base||||Sun Microsystems
|-
| Pavel Janík|| X || pjanik||paveljanik||PL Czech native-lang project, CL l10n, CC, ESC, l10n builds||
|-
| Berry Jia|| X || berryjia||||||Sun Microsystems
|-
| Chuang Jiang || || jiangc || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Jingchuan Kang|| || kangjingchuan || jingchuan || Surrogates in Unicode || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Pascal Junck|| || pjunck||||||Sun Microsystems
|-
| [[User:pj@openoffice.org|Peter Junge]]|| X || pj|| peter13j|| OOo community contact for my Chinese Employer, QA||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Christian Junker|| || Cyb||christianju||API||Trees For Life
|-
| Etsushi Kato || X || ekato || || Mac OS X Port || Independent
|-
| Hirano Kazunari|| || khirano||||Japanese||
|-
| Dhananjay Keskar|| X || dkeskar ||dkeskar||Performance,Buildbot,cat-herder||Intel Corporation
|-
| Robert Kinsella|| || rkinsella||||||Sun Microsystems
|-
| Volodymyr Khrystynych|| || volody||||XML Filter||
|-
| Matthias Klose|| || doko||doko||Ubuntu, gcc, python packager||Canonical, Inc.
|-
| Laszlo Kovacs|| || lkovacs||||Documentation||
|-
| Tobias Krause|| X || tkr||||ucb||Sun Microsystems
|-
| Martin Kretzschmar|| X || mkretzschmar||martink||Gnome / Debian||Student
|-
| Will Lachance|| || wlach||wlach_||Word Perfect File Filters||Net Integration Technologies, Inc.
|-
| Thomas Lange|| X || tl||tl13||||Sun Microsystems
|-
| Lars Langhans|| X || lla||||||Sun Microsystems
|-
| Hans-Joachim Lankenau|| X || hjs||ause||dmake makefile expert, RE||Sun Microsystems
|-
| Németh László|| X || nemeth||||PL lingucomponent||
|-
| Jakob Lechner|| X || jakob_lechner||||Writer||Fabalabs
|-
| Michael Leibowitz|| X || mikeleib ||mikeleib||performance||Intel Corporation
|-
| Wind Li|| X || windly||||Address books||
|-
|Jian Li || || lijian || lijian|| Writer|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yuan Li || || liyuan || || PyUNO, Async dialogs || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Weike Liang || || liangweike || liangweike || Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Ping Liao|| || pliao||||||
|-
| Tor Lillqvist|| X || tml||tml_||||Novell, Inc.
|-
| Joachim Lingner|| X || jl||||Java, CLI||Sun Microsystems
|-
| Christian Lippka|| X || cl || cl ||Graphic Applications||Sun Microsystems
|-
| Mindy Liu|| || mindyliu||||||
|-
|Jianli Liu || || liujl|| liujianli || Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|[[User:liutao | LiuTao]] || X || liutao || liutao || PyUNO, Async dialogs,slideshow,modularization in SW || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|YU Liu || X || ch2000liuy || LiuYU || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yuhua Liu || || liuyuhua|| yuhua|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| [[User:Dl|Dieter Loeschky]]|| X || dl ||||PL: ODF Toolkit||Sun Microsystems
|-
| [[User:fl|Frank Loehmann]]|| X || fl ||frankl||PL [http://ux.openoffice.org User Experience]||Sun Microsystems
|-
| Philipp Lohmann|| X || pl||PhilippL||VCL/X11 (GSL) hacker||Sun Microsystems
|-
| Michel Loiseleur|| || mloiseleur|| coren`|| Bugfixes ||Linagora
|-
| Jackson Low|| X || xxjack12xx||||Porting||
|-
| Patrick Luby|| || pluby||||Mac||
|-
|Jingrong Luo || || Luo Jingrong|| Luo Jingrong|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Xugang Lv || || lvxg || lvxg || XML Writer || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Prasad Madhav || X || pmadhav || pmadhav || Buildbot || Intern@Intel
|-
| Babak Mahbod|| || bmahbod||||||
|-
| Martin Maher|| || mmaher||||Writer & Filter chap||
|-
| Nakata Maho|| X || maho||_maho_||PL QA, PL JA, FreeBSD guy||Independent
|-
|Yonggang Mao || X || maoyonggang|| maoyg|| Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yue Lv || || lvyue || lvyue || Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
|-|
| Shane M Mathews|| X || smmathews|| smmathews ||[[Impress:_OpenGL_rendered_transitions]]||student
|-
| Frank Mau|| X || fma||||tooling||Sun Microsystems
|-
| [[User:smsm1|Shaun McDonald]] || X || smsm1 || shaunmcdonald || Mac Port, buildbot MacPort1 || Graduate
|-
| Caolán McNamara|| X || cmc||caolan||CL Writer & Filter man|| [http://www.redhat.com Red Hat Inc.]
|-
| Michael Meeks|| X || mmeeks||michael_||ugly hack-er, ESC||Novell, Inc.
|-
| Frank Meies|| X || fme||||Writer||Sun Microsystems
|-
| Federico Mena-Quintero|| || federicomena||federico||perfectionist||Novell, Inc.
|-
| Ismael Merzaq|| X || isma87||ismael_||Mac OSX native porting||Student
|-
| Michael Mi|| || mmi||||||
|-
| Björn Michaelsen|| X || b_michaelsen ||Sweetshark|| ||Sun Microsystems
|-
| Björn Milcke|| X || bm||bm_||Chart||Sun Microsystems
|-
| Petr Mladek|| || pmladek||pmladek||SUSE RPMs, ooo-build releases||Novell, Inc.
|-
| Cyrille Moureaux|| X || cyrillem||Cyrille||||Sun Microsystems
|-
| [[User:Mmp|Matthias Müller-Prove]]|| X || mmp|| mprove|| [[User Experience]], http://ux.openoffice.org || Sun Microsystems
|-
| Takashi Nakamoto|| || bluedwarf|| || ||
|-
| Jan Navrátil || X || jnavrati || jnavrati || || [http://www.redhat.com Red Hat Inc.]
|-
| Niklas Nebel|| X || nn||||PL [[Calc]]||Sun Microsystems
|-
| Christoph Neumann|| X || cn||||[[UnoApiTest]]||Sun Microsystems
|-
| Frank Neumann|| X || fne||||MacPort||Sun Microsystems
|-
| NicelKM|| X || mnicel||nicel||||Novell, Inc.
|-
| Jan Nieuwenhuizen|| X || jcn||janneke||Layout code, hacker ||Novell, Inc.
|-
| [[User:ChristophNoack|Christoph Noack]]|| X || christophnoack ||christoph_n||CL [http://ux.openoffice.org User Experience]||
|-
| Bertram Nolte|| || bnolte||||||
|-
| Tomas O'Connor|| || toconnor||||Scripting Framework||
|-
| Maximilian Odendahl|| X || mod||mod||[[Notes2]] [[SQL_Syntax_Highlighting]]|| Student / SEPT-Solutions
|-
| Lars Oppermann|| X || lo||||||
|-
| Rakesh Pandit || X || rakeshpandit|| chacha_chaudhry|| Education Project - Starmath/fix module warnings|| Education Project
|-
| Rodrigo Parra Novo|| X || rodarvus||rodarvus||Gnumeric/Abiword OpenDocument Format support and port to Maemo||INdT (Instituto Nokia de Tecnologia)
|-
| Pierre Pasteau|| X || pastea_p || pierrep|| Education Project, SeaMonkey migration || Education Project
|-
| Edward Peterlin|| X || OPENSTEP||||Mac||
|-
| [[User:Fpe|Frank Peters]]|| X || fpe||||CL Documentation||Sun Microsystems
|-
| Christof Pintaske|| X || cp||||||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Sebastien Plisson|| X || plipli||plipli||Developer on Aqua port||OO Aqua Port
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality||Sun Microsystems
|-
| Jonathan Pryor|| || jpryor || jonp || || Novell, Inc.
|-
| Canghua Qu|| || quch || Canghua || AutoTest, Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Volker Quetschke|| X || vq||vq||W32-tcsh/bash build environment and dmake Hacker, ESC||Gravity Waves
|-
| Tino Rachui|| X || tra||tinor||GSL/Unix Hacker||Sun Microsystems
|-
| Goran Rakić || X ||goranrakic || || Serbian Native-Lang PL ||
|-
| [[User:Kr|Kay Ramme]]|| X || kr||||PL UDK||Sun Microsystems
|-
| [[User:ErAck|Eike Rathke]]|| X || er||erAck||CL [[Calc]], engine; CL i18n; stricken with number formatter||Sun Microsystems
|-
| Michael Rauch|| X || mrauch||||NetBSD||
|-
| Jens-Heiner Rechtien|| X || hr||blauwal||RE; OOo SCM (CVS, CWS tooling); Porting; Compilers||Sun Microsystems
|-
| Daniel Rentz|| X || dr|| drr ||[[Calc]] Excel filter, UI||Sun Microsystems
|-
| Florian Reuter|| X || flr||||Writer filters||Novell, Inc.
|-
| Georg Richter|| X || grichter||georg||Base, native MySQL driver||MySQL AB
|-
| G. Roderick Singleton|| || grsingleton||grsingleton||Documentation||pathtech.org
|-
| Hennes Rohling|| X || hro||||GSL & Util||Sun Microsystems
|-
| Bibek Sahu|| || Bibek||bibek||Impress pieces||Trees For Life
|-
| Andreas Schlüns|| X || as||||Framework||Sun Microsystems
|-
| Ingo Schmidt|| X || is||||(Native) Installation||Sun Microsystems
|-
| [[User:Jsc|Jürgen Schmidt]]|| X || jsc||jsc||PL API, CL Extensions, UNO, SDK||Sun Microsystems
|-
| Stephan Schäfer|| X || ssa||ssa||VCL||Sun Microsystems
|-
| Frank Schönheit|| X || fs||FrankS||Database Access, Forms||Sun Microsystems
|-
| [[User:Sus|Svante Schubert]]|| X || sus||Svante||XML & ODFTOOLKIT co-lead, ODF TC, ODF SC Metadata||Sun Microsystems
|-
| [[User:Sts|Stella Schulze]]|| X || sts||||[http://ui.openoffice.org/nonav/VisualDesign/ Visual Design]||Sun Microsystems
|-
| Julian Seward || || sewardj || || valgrind ||
|-
| Darragh Sherwin|| || dsherwin||darragh||E-Legislation / E-GovSystems||Propylon
|-
|Lei shi || || shilei|| sl || Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Zhoubo Shi || || shizhoubo || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Raul Siddhartha|| || rsiddhartha||raul||GTK File Selector||Novell, Inc.
|-
| Sarah Smith|| || ssmith||||||
|-
| [[User:mox|Mox Soini]] || X || mox || Moxed || Mac Porting ||
|-
| Rajesh Sola|| || rajeshsola||sola||misc.||NOSIP
|-
| Kai Sommerfeld|| X || kso||||manager & hacker||Sun Microsystems
|-
| Oliver Specht|| X || os||||PL UI||Sun Microsystems
|-
| Jörg Spindler|| || jspindler||||||
|-
| Fridrich Štrba|| X || fridrich_strba||Fridrich||Word Perfect Hacker||Novell, Inc.
|-
| Keith Stribley|| X || kstribley||||Graphite fonts, Myanmar l10n||
|-
| Ulf Stroehler|| || us||||||Sun Microsystems
|-
| [[User:Muthusuba|Muthu Subramanian]]|| X || muthusuba||muthusuba||misc.||
|-
| Louis Suárez-Potts|| || louis||louis||Community Manager||Collab.net
|-
| Claus Sørensen|| || cs||c26n,cHBs,chbs||Danish Localization and Project Management Tool(oopm)||ProFOSS
|-
|Quanfa Tang || || tqfa|| tangquanfa|| Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| David Tardon || X || dtardon || dtardon || || [http://www.redhat.com Red Hat Inc.]
|-
| Stefan Taxhet|| X || st||stx12||CC, interpersonal problem fixer||Sun Microsystems
|-
| Armin Theissen|| || armin||||||
|-
| Caio Tiago Oliveira|| X || asrail||asrail||CL QA, release testing pt-BR builds||BrOffice.org
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt|| rtimm ||RE||Sun Microsystems
|-
| [[User:mt|Malte Timmermann]]|| X || mt|| Malte || Accessibility, Security, Performance||Sun Microsystems
|-
| Gerhard Tonn|| || tonn||||s390||
|-
| Willem van Dorp|| || willem.vandorp||||||
|-
| Tom Verbeek|| X || tv||||Wizards, Art team||Sun Microsystems
|-
| Sander Vesik|| || svesik||||||
|-
| Daniel Vogelheim|| X || dvo||||XML||
|-
| Mikhail Voitenko|| X || mav||mav||Framework||Sun Microsystems
|-
| Robert Vojta|| X || rvojta||rvojta||VBA Interop||
|-
| Dirk Völzke|| X || dv||||Installation||Sun Microsystems
|-
| [[User:Sparcmoz|Jim Watson]]|| X || sparcmoz|| sparcmoz||GNU Linux sparc porter||clug.org.au
|-
| [[User:Weiz |Zhao Wei ]] || || weiz || weiz || Chart2 || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Armin Weiss|| X || aw||||||Sun Microsystems
|-
| Gerd Weiss|| X || gm||||RE||Sun Microsystems
|-
| Dan Williams|| X || fa||dcbw||Mac et. al. hacker|| [http://www.redhat.com Red Hat Inc.]
|-
|[[User:wuy|Yan Wu]] || X || wuy || ||Framework || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Stephan Wunderlich|| X || sw||||||
|-
|Dehua Xu || || xudehua || xudh || Release || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Kohei Yoshida|| X || kohei||kohei_||[[Calc]] hacker, Calc optimization solver developer||Novell, Inc.
|-
| George Zahopoulos|| X || georgez||||||
|-
| Kurt Zenker|| X || kz||smoketester||RE||Sun Microsystems
|-
|Huajun Zhang || || zhanghuajun|| zhanghj|| SW ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|[[User:Zhangxiaofei|Xiaofei Zhang]]|| || Zhangxiaofei || zhangxiaofei/FelixZ || [[Framework]] ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Jianwei Zhao || || zhaojianwei || zhaojianwei || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sheng zhao|| X || jacky23 || ||OdfToolKit_odf4j || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Claudio F Filho|| || filhocf||filhocf||Brazilian portuguese Localization||BrOffice.org
|-
| Xiaoyang Yu|| || || ||Disk block reordering||Intel Corporation
|-
| Antonio Xu|| X || antoxu || antoxu || Async dialogs, PRC improvements || Intel Corporation
|-
| Rail Aliev || X || rail || rail || Ru and Tr NL Co-lead || Infra-Resource
|-
| Jeremy Zheng|| X || zhiming || Jeremy || Async dialogs, PRC improvements || Intel Corporation
|-
| [[User:Schmidtm|Matthias Schmidt]] || || schmidtm || schmidtm || Mac OSX Aqua Port || Sun Microsystems
|-
| Yuri Dario || || ydario || Paperino || OS/2 Port || Serenity Systems intl
|-
| Fong Lin || X || pflin || Fong || VBA Interop, Scripting, CJK Enhancement || Novell, Inc.
|-
| [[User:jza|Alexandro Colorado]]|| X || jza || jza|| CL [[OOoES|ES]] ||
|-
| Sunil Amitkumar Janki || || sjanki || sjanki || GNU Linux mipsel porter ||
|-
| [[User:Rescue|Joey Stanford]] || || Rescue/k0fcc || Rinchen || CL [http://eo.openoffice.org/ Esperanto native-lang project] || [http://canonical.com Canonical] ||
|-
| Mingfei Jia || X || jiamingfei || || Lotus Smart Suite filter || IBM Corp.
|-
| Xing Li || X || lixxing || || Accessibility || IBM Corp.
|-
| Wei Guo SHI || X || shiwg || || Accessibility and Smart Suite filter || IBM Corp.
|-
| Takashi Ono || X || tono || || MinGW port || Independent
|-
| Yu Guoqiang|| X || yugq || yugq|| Performance || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Liu YiSong|| || Liu YiSong || Liu YiSong|| PYUNO || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Bo Han || X || hanbo || hanbo || VBA Interop || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name ||CVS||@openoffice.org || [[IRC Communication]] || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||||sba||||writer||||Sun Microsystems
|-
| Thorsten Bosbach||X||tbo||||framework, testautomation||framework test automation||Sun Microsystems
|-
| Oliver Craemer||X||oc||||[[Calc]], testautomation||calc test automation||Sun Microsystems
|-
| Helge Delfs||X||hde||||testautomation, writer||Test automation||Sun Microsystems
|-
| Fredrik Haegg||X||fha||||writer, testautomation||Writer test automation||Sun Microsystems
|-
| Hasan Ilter||||hi||||writer, printing, pdf export||||Sun Microsystems
|-
| Michael Rüß||||mru||||writer, word im/export||||Sun Microsystems
|-
| Éric Savary||||es||||writer, accessibility||||Sun Microsystems
|-
| [[User:jsi|Joerg Sievers]]||X||jsi||jsi_sun||chart, xml, testautomation||Chart2, XML test automation||Sun Microsystems
|-
| Joerg Skottke||X||jsk||skotti||framework, qa/qatesttool||Framework test automation||Sun Microsystems
|-
| Marc Neumann||X||msc||||database, testautomation||Database access test automation||Sun Microsystems
|-
| Chris Lukasiak||||clu||||database||||Sun Microsystems
|-
| Frank Stecher||||fst||||[[Calc]]||||Sun Microsystems
|-
| Jack Warchold|||| jw||||writer, import/export filters||||Sun Microsystems
|-
| Uwe Luebbers||||ul||||framework||||Sun Microsystems
|-
| Thorsten Martens||||tm||||framework||||Sun Microsystems
|-
| Olaf Felka|||| of||||framework, installation||||Sun Microsystems
|-
| Thomas Klarhoefer||||kla||||chart||||Sun Microsystems
|-
| Wolfram Garten||X|| wg||||draw, impress||draw, impress test automation||Sun Microsystems
|-
| Christian Guenther||||cgu||||draw, impress||||Sun Microsystems
|-
| [[User:Thorsten_Ziehm|Thorsten Ziehm]]||||| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

== Related Pages ==
* [[Commit Rights]]
* [[Contributing Patches]]
* [[User_Experience/Community|User Experience Team]]
* A map of OOo developers around the world is available at http://www.frappr.com/ooodev, please add yourself to the map if you're involved in OOo development. It's just fun to see who's where :-)

[[Category:Development]]
[[Category:Alpha Centauri]]

DomainDeveloper

2009-01-13T18:53:10Z

Sus: /* Developers */

A mapping of names to OOo accounts.

Abbrev.:

* PL : Project Lead
* CL : Project Co-Lead
* CC : Community Council Member
* ESC : Engineering Steering Committee Member
* CVS : has write access to the OOo CVS repository

----

=== Developers ===

{| class="prettytable sortable"
|-
! Name || CVS || @openoffice.org || [[IRC Communication]] || Notes || Affiliation
|-
| Volker Ahrendt|| X || va||||||Sun Microsystems
|-
| Kai Ahrens|| X || ka || Kai_Ahrens ||PL Graphic Applications||Sun Microsystems
|-
| Gene Anaya|| || ganaya||||||
|-
| Joost Andrae|| X || ja||ja||CL qa, release testing en-US builds and releasing builds||Sun Microsystems
|-
| Eric Bachard|| X || ericb||ericb2|| CL Education, Mac OSX/Linux PPC port ||Education project
|-
| Kai Backman|| || kaib ||KaiB||||
|-
| Sascha Ballach|| X || sab||||||
|-
| Jayant Balraj Madavi|| || jayant_madavi||aZEN_JM||Connectivity / Database||Novell, Inc.
|-
| Jörg Barfurth|| X || jb||JoergB||Configuration Util||Sun Microsystems
|-
| Omer Bar-or|| X || cremlae||cremlae||Mac porting||Google Summer of Code
|-
| Mathias Bauer|| X || mba||||PL Writer, CL Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Novell, Inc.
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stephan Bergmann|| X || sb||||CL UDK||Sun Microsystems
|-
| Andreas Bille|| X || abi||||||Sun Microsystems
|-
| Éric Bischoff|| X || ebischoff||ebischoff||KDE A/B driver||Bureau Cornavin
|-
| Nick Blievers|| X || nick||||IRIX||
|-
| Daniel Boelzle|| X || dbo||||UNO core/bridges/packages||Sun Microsystems
|-
| Oliver Bolte|| X || obo||||RE||Sun Microsystems
|-
| Rafaella Braconi|| || coni||Rafaella ||PL l10n, Globalization Program Manager||Sun Microsystems
|-
| Michael Brauer|| X || mib||||PL XML||Sun Microsystems
|-
| Oliver Braun|| X || obr||obr||System Integration/Accessibility Hacker||Sun Microsystems
|-
| Andreas Bregas|| X || ab||||StarBasic||Sun Microsystems
|-
| Jörg Brunsmann|| || jbrunsmann||||UDK||
|-
| Jörg Budischewski|| || jbu||PyUNO hacker||||Sun Microsystems
|-
| Peter Burow|| X || pb||plumbumm||UI||Sun Microsystems
|-
| Aidan Butler|| || aidan||||XML filters||
|-
| Giuseppe Castagno || X || beppec56 || beppec56_ or beppe_c || PDF output
|-
| [[User:ScottCarr|Scott Carr]] || X || kcarr||kcarr||PL Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
| Jinhong Chen || || chainchen || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Xiuzhi Cheng|| X || xzcheng || xiuzhi|| ESC,Xml,ODF|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| Michael Cziebalski|| || mci||||||
|-
| [[User:pdefilippis|Pierre de Filippis]]|| X || pdefilippis||aliscafo||Mac OSX native porting||
|-
| Andrew Dent|| X ||ace_dent||ace_dent||ui/custom_images||
|-
| Naren Devaiah|| || ||ndev||Performance||Intel Corporation
|-
| Quangang Dong|| || donqg || dongqg || Layout || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Nitin Dongre|| || ||nitin_BITS||||Novell, Inc.(intern)
|-
| Radek Doulik|| || radekdoulik||rodo_||Canvas hacker||Novell, Inc.
|-
| Carsten Driesner|| X || cd|| cd_oo ||PL Framework||Sun Microsystems
|-
| Yunfen Du || X || duyunfen|| dyf|| Base ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-

| Herbert Duerr|| X || hdu||hdu_hh||GSL||Sun Microsystems
|-
| Oliver Düsterhoff|| X || od||Writer||||Sun Microsystems
|-
| [[User:bei|Bernd Eilers]]|| X || bei||rfc821||[[EIS]]||Sun Microsystems
|-
| René Engelhard|| X || rene||_rene_||config_office, Debian packager||Debian
|-
| [[User:Pereriksson|Per Eriksson]] || || pereriksson || || CL, MarCon Sweden ||
|-
| Yaqiong Fang || X || fangyq || fangyq|| Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Hubert Figuière|| X || hub || hub || PPTX || Novell, Inc.
|-
| Andre Fischer|| X || af||||Impress||Sun Microsystems
|-
| Uwe Fischer || X || ufi || ufiooo || Application Help || Sun Microsystems
|-
| Ken Foskey|| || waratah||waratah||config_office/dmake man||slug.org.au
|-
| Duncan Foster|| || dfoster||||||
|-
| David Fraser|| || davidfraser||davidfraser||South African translations, multilingual builds||translate.org.za
|-
| [[User:Nf|Nils Fuhrmann]]|| || nf||SunNF||||Sun Microsystems
|-
| Martin Gallwey|| X || mtg||marty_||XML/Writer/packaging||
|-
| Pierre-Andre Galmes || || pagalmes || pagalmes || Chart2 ||StarXpert
|-
| Tony Galmiche|| X || tonygalmiche||||CL FR native-lang project||
|-
| Sunil Gandhi|| || ||tyro||||NOSIP
|-
| Peng Gao || || Gao Peng|| Gao Peng || writer|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Zemin Gao || || gaozemin|| gaozm || Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sophie Gautier|| X || sgauti|| sophi || ||.
|-
| Vladimir Glazounov|| X || vg||||RE||Sun Microsystems
|-
| Laurent Godard || X || laurentgodard || lgodard || CC, PL Extensions, Fr Native-lang Project || inDesko/Nuxeo
|-
| Jody Goldberg|| X || jodygoldberg||jody||[[Calc]] spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||Sun Microsystems
|-
| [[User:Sg|Steffen Grund]]|| X || sg|| || NetBeans Integration ||Sun Microsystems
|-
| Bettina Haberer|| || bh||||RFEOwner||Sun Microsystems
|-
| Ingrid Halama|| X || iha||||Chart||Sun Microsystems
|-
| Chris Halls|| X || haggai||haggai||Debian packager&misc. hacker||Credativ Ltd., Debian
|-
| Gregor Hartmann|| X || gh|| Lachs ||Testtool, gsicheck, buildbot||Sun Microsystems
|-
| Bustamam Harun|| || bustamam||||Malaysian stuff||
|-
| Kevin Hendricks|| X || khendricks||||PL Lingucomponent, PowerPC||
|-
| Con Hennessy|| || cphennessy||cph2 or cph_||hacker & former council person||OpenApp
|-
| Ivo Hinkelmann|| X || ihi||ivo||l10n tooling/general/RE||Sun Microsystems
|-
| Eric Hoch|| X || maveric||mav_eric||Mac Porting||
|-
| [[User:Lutz_Hoeger|Lutz Hoeger]]|| X || lh ||lutzh||||Sun Microsystems
|-
| Ilko Höpping|| X || ih||||||Sun Microsystems
|-
| Jan Holešovský|| X || kendy||kendy||KDE integration||Novell, Inc.
|-
| Martin Hollmichel|| X || mh||Ratte/Nesshof||Build Maestro, PL External, Tools, Porting, CC||Sun Microsystems
|-
| Karl Hong|| X || khong||||i18n, CJK expert||Sun Microsystems
|-
| Matthias Huetsch|| X || mhu||||Performance/strategy, PL UCB, CC, ESC||Sun Microsystems
|-
| Michael Hönnig|| X || mi||||PL API||
|-
| [[User:icobgr|Hristo Hristov]] || || icobgr || icobgr || PL Bulgarian native-lang project ||
|-
| Sven Jacobi|| X || sj||||Escherwizard||Sun Microsystems
|-
| Jörg Jahnke|| || jj||||tooling||Sun Microsystems
|-
| Christian Jansen|| || cj ||||Menu and Toolbar?||Sun Microsystems
|-
| Ocke Janssen|| X || oj||Base||||Sun Microsystems
|-
| Pavel Janík|| X || pjanik||paveljanik||PL Czech native-lang project, CL l10n, CC, ESC, l10n builds||
|-
| Berry Jia|| X || berryjia||||||Sun Microsystems
|-
| Chuang Jiang || || jiangc || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Jingchuan Kang|| || kangjingchuan || jingchuan || Surrogates in Unicode || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Pascal Junck|| || pjunck||||||Sun Microsystems
|-
| [[User:pj@openoffice.org|Peter Junge]]|| X || pj|| peter13j|| OOo community contact for my Chinese Employer, QA||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Christian Junker|| || Cyb||christianju||API||Trees For Life
|-
| Etsushi Kato || X || ekato || || Mac OS X Port || Independent
|-
| Hirano Kazunari|| || khirano||||Japanese||
|-
| Dhananjay Keskar|| X || dkeskar ||dkeskar||Performance,Buildbot,cat-herder||Intel Corporation
|-
| Robert Kinsella|| || rkinsella||||||Sun Microsystems
|-
| Volodymyr Khrystynych|| || volody||||XML Filter||
|-
| Matthias Klose|| || doko||doko||Ubuntu, gcc, python packager||Canonical, Inc.
|-
| Laszlo Kovacs|| || lkovacs||||Documentation||
|-
| Tobias Krause|| X || tkr||||ucb||Sun Microsystems
|-
| Martin Kretzschmar|| X || mkretzschmar||martink||Gnome / Debian||Student
|-
| Will Lachance|| || wlach||wlach_||Word Perfect File Filters||Net Integration Technologies, Inc.
|-
| Thomas Lange|| X || tl||tl13||||Sun Microsystems
|-
| Lars Langhans|| X || lla||||||Sun Microsystems
|-
| Hans-Joachim Lankenau|| X || hjs||ause||dmake makefile expert, RE||Sun Microsystems
|-
| Németh László|| X || nemeth||||PL lingucomponent||
|-
| Jakob Lechner|| X || jakob_lechner||||Writer||Fabalabs
|-
| Michael Leibowitz|| X || mikeleib ||mikeleib||performance||Intel Corporation
|-
| Wind Li|| X || windly||||Address books||
|-
|Jian Li || || lijian || lijian|| Writer|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yuan Li || || liyuan || || PyUNO, Async dialogs || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Weike Liang || || liangweike || liangweike || Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Ping Liao|| || pliao||||||
|-
| Tor Lillqvist|| X || tml||tml_||||Novell, Inc.
|-
| Joachim Lingner|| X || jl||||Java, CLI||Sun Microsystems
|-
| Christian Lippka|| X || cl || cl ||Graphic Applications||Sun Microsystems
|-
| Mindy Liu|| || mindyliu||||||
|-
|Jianli Liu || || liujl|| liujianli || Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|[[User:liutao | LiuTao]] || X || liutao || liutao || PyUNO, Async dialogs,slideshow,modularization in SW || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|YU Liu || X || ch2000liuy || LiuYU || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yuhua Liu || || liuyuhua|| yuhua|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| [[User:Dl|Dieter Loeschky]]|| X || dl ||||PL: ODF Toolkit||Sun Microsystems
|-
| [[User:fl|Frank Loehmann]]|| X || fl ||frankl||PL [http://ux.openoffice.org User Experience]||Sun Microsystems
|-
| Philipp Lohmann|| X || pl||PhilippL||VCL/X11 (GSL) hacker||Sun Microsystems
|-
| Michel Loiseleur|| || mloiseleur|| coren`|| Bugfixes ||Linagora
|-
| Jackson Low|| X || xxjack12xx||||Porting||
|-
| Patrick Luby|| || pluby||||Mac||
|-
|Jingrong Luo || || Luo Jingrong|| Luo Jingrong|| ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Xugang Lv || || lvxg || lvxg || XML Writer || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Prasad Madhav || X || pmadhav || pmadhav || Buildbot || Intern@Intel
|-
| Babak Mahbod|| || bmahbod||||||
|-
| Martin Maher|| || mmaher||||Writer & Filter chap||
|-
| Nakata Maho|| X || maho||_maho_||PL QA, PL JA, FreeBSD guy||Independent
|-
|Yonggang Mao || X || maoyonggang|| maoyg|| Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Yue Lv || || lvyue || lvyue || Calc ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
|-|
| Shane M Mathews|| X || smmathews|| smmathews ||[[Impress:_OpenGL_rendered_transitions]]||student
|-
| Frank Mau|| X || fma||||tooling||Sun Microsystems
|-
| [[User:smsm1|Shaun McDonald]] || X || smsm1 || shaunmcdonald || Mac Port, buildbot MacPort1 || Graduate
|-
| Caolán McNamara|| X || cmc||caolan||CL Writer & Filter man|| [http://www.redhat.com Red Hat Inc.]
|-
| Michael Meeks|| X || mmeeks||michael_||ugly hack-er, ESC||Novell, Inc.
|-
| Frank Meies|| X || fme||||Writer||Sun Microsystems
|-
| Federico Mena-Quintero|| || federicomena||federico||perfectionist||Novell, Inc.
|-
| Ismael Merzaq|| X || isma87||ismael_||Mac OSX native porting||Student
|-
| Michael Mi|| || mmi||||||
|-
| Björn Michaelsen|| X || b_michaelsen ||Sweetshark|| ||Sun Microsystems
|-
| Björn Milcke|| X || bm||bm_||Chart||Sun Microsystems
|-
| Petr Mladek|| || pmladek||pmladek||SUSE RPMs, ooo-build releases||Novell, Inc.
|-
| Cyrille Moureaux|| X || cyrillem||Cyrille||||Sun Microsystems
|-
| [[User:Mmp|Matthias Müller-Prove]]|| X || mmp|| mprove|| [[User Experience]], http://ux.openoffice.org || Sun Microsystems
|-
| Takashi Nakamoto|| || bluedwarf|| || ||
|-
| Jan Navrátil || X || jnavrati || jnavrati || || [http://www.redhat.com Red Hat Inc.]
|-
| Niklas Nebel|| X || nn||||PL [[Calc]]||Sun Microsystems
|-
| Christoph Neumann|| X || cn||||[[UnoApiTest]]||Sun Microsystems
|-
| Frank Neumann|| X || fne||||MacPort||Sun Microsystems
|-
| NicelKM|| X || mnicel||nicel||||Novell, Inc.
|-
| Jan Nieuwenhuizen|| X || jcn||janneke||Layout code, hacker ||Novell, Inc.
|-
| [[User:ChristophNoack|Christoph Noack]]|| X || christophnoack ||christoph_n||CL [http://ux.openoffice.org User Experience]||
|-
| Bertram Nolte|| || bnolte||||||
|-
| Tomas O'Connor|| || toconnor||||Scripting Framework||
|-
| Maximilian Odendahl|| X || mod||mod||[[Notes2]] [[SQL_Syntax_Highlighting]]|| Student / SEPT-Solutions
|-
| Lars Oppermann|| X || lo||||||
|-
| Rakesh Pandit || X || rakeshpandit|| chacha_chaudhry|| Education Project - Starmath/fix module warnings|| Education Project
|-
| Rodrigo Parra Novo|| X || rodarvus||rodarvus||Gnumeric/Abiword OpenDocument Format support and port to Maemo||INdT (Instituto Nokia de Tecnologia)
|-
| Pierre Pasteau|| X || pastea_p || pierrep|| Education Project, SeaMonkey migration || Education Project
|-
| Edward Peterlin|| X || OPENSTEP||||Mac||
|-
| [[User:Fpe|Frank Peters]]|| X || fpe||||CL Documentation||Sun Microsystems
|-
| Christof Pintaske|| X || cp||||||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Sebastien Plisson|| X || plipli||plipli||Developer on Aqua port||OO Aqua Port
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality||Sun Microsystems
|-
| Jonathan Pryor|| || jpryor || jonp || || Novell, Inc.
|-
| Canghua Qu|| || quch || Canghua || AutoTest, Graphics || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Volker Quetschke|| X || vq||vq||W32-tcsh/bash build environment and dmake Hacker, ESC||Gravity Waves
|-
| Tino Rachui|| X || tra||tinor||GSL/Unix Hacker||Sun Microsystems
|-
| Goran Rakić || X ||goranrakic || || Serbian Native-Lang PL ||
|-
| [[User:Kr|Kay Ramme]]|| X || kr||||PL UDK||Sun Microsystems
|-
| [[User:ErAck|Eike Rathke]]|| X || er||erAck||CL [[Calc]], engine; CL i18n; stricken with number formatter||Sun Microsystems
|-
| Michael Rauch|| X || mrauch||||NetBSD||
|-
| Jens-Heiner Rechtien|| X || hr||blauwal||RE; OOo SCM (CVS, CWS tooling); Porting; Compilers||Sun Microsystems
|-
| Daniel Rentz|| X || dr|| drr ||[[Calc]] Excel filter, UI||Sun Microsystems
|-
| Florian Reuter|| X || flr||||Writer filters||Novell, Inc.
|-
| Georg Richter|| X || grichter||georg||Base, native MySQL driver||MySQL AB
|-
| G. Roderick Singleton|| || grsingleton||grsingleton||Documentation||pathtech.org
|-
| Hennes Rohling|| X || hro||||GSL & Util||Sun Microsystems
|-
| Bibek Sahu|| || Bibek||bibek||Impress pieces||Trees For Life
|-
| Andreas Schlüns|| X || as||||Framework||Sun Microsystems
|-
| Ingo Schmidt|| X || is||||(Native) Installation||Sun Microsystems
|-
| [[User:Jsc|Jürgen Schmidt]]|| X || jsc||jsc||PL API, CL Extensions, UNO, SDK||Sun Microsystems
|-
| Stephan Schäfer|| X || ssa||ssa||VCL||Sun Microsystems
|-
| Frank Schönheit|| X || fs||FrankS||Database Access, Forms||Sun Microsystems
|-
| Svante Schubert|| X || sus||Svante||XML & ODFTOOLKIT co-lead, ODF TC, ODF SC Metadata||Sun Microsystems
|-
| [[User:Sts|Stella Schulze]]|| X || sts||||[http://ui.openoffice.org/nonav/VisualDesign/ Visual Design]||Sun Microsystems
|-
| Julian Seward || || sewardj || || valgrind ||
|-
| Darragh Sherwin|| || dsherwin||darragh||E-Legislation / E-GovSystems||Propylon
|-
|Lei shi || || shilei|| sl || Graphics|| [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Zhoubo Shi || || shizhoubo || || || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Raul Siddhartha|| || rsiddhartha||raul||GTK File Selector||Novell, Inc.
|-
| Sarah Smith|| || ssmith||||||
|-
| [[User:mox|Mox Soini]] || X || mox || Moxed || Mac Porting ||
|-
| Rajesh Sola|| || rajeshsola||sola||misc.||NOSIP
|-
| Kai Sommerfeld|| X || kso||||manager & hacker||Sun Microsystems
|-
| Oliver Specht|| X || os||||PL UI||Sun Microsystems
|-
| Jörg Spindler|| || jspindler||||||
|-
| Fridrich Štrba|| X || fridrich_strba||Fridrich||Word Perfect Hacker||Novell, Inc.
|-
| Keith Stribley|| X || kstribley||||Graphite fonts, Myanmar l10n||
|-
| Ulf Stroehler|| || us||||||Sun Microsystems
|-
| [[User:Muthusuba|Muthu Subramanian]]|| X || muthusuba||muthusuba||misc.||
|-
| Louis Suárez-Potts|| || louis||louis||Community Manager||Collab.net
|-
| Claus Sørensen|| || cs||c26n,cHBs,chbs||Danish Localization and Project Management Tool(oopm)||ProFOSS
|-
|Quanfa Tang || || tqfa|| tangquanfa|| Calc || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| David Tardon || X || dtardon || dtardon || || [http://www.redhat.com Red Hat Inc.]
|-
| Stefan Taxhet|| X || st||stx12||CC, interpersonal problem fixer||Sun Microsystems
|-
| Armin Theissen|| || armin||||||
|-
| Caio Tiago Oliveira|| X || asrail||asrail||CL QA, release testing pt-BR builds||BrOffice.org
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt|| rtimm ||RE||Sun Microsystems
|-
| [[User:mt|Malte Timmermann]]|| X || mt|| Malte || Accessibility, Security, Performance||Sun Microsystems
|-
| Gerhard Tonn|| || tonn||||s390||
|-
| Willem van Dorp|| || willem.vandorp||||||
|-
| Tom Verbeek|| X || tv||||Wizards, Art team||Sun Microsystems
|-
| Sander Vesik|| || svesik||||||
|-
| Daniel Vogelheim|| X || dvo||||XML||
|-
| Mikhail Voitenko|| X || mav||mav||Framework||Sun Microsystems
|-
| Robert Vojta|| X || rvojta||rvojta||VBA Interop||
|-
| Dirk Völzke|| X || dv||||Installation||Sun Microsystems
|-
| [[User:Sparcmoz|Jim Watson]]|| X || sparcmoz|| sparcmoz||GNU Linux sparc porter||clug.org.au
|-
| [[User:Weiz |Zhao Wei ]] || || weiz || weiz || Chart2 || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Armin Weiss|| X || aw||||||Sun Microsystems
|-
| Gerd Weiss|| X || gm||||RE||Sun Microsystems
|-
| Dan Williams|| X || fa||dcbw||Mac et. al. hacker|| [http://www.redhat.com Red Hat Inc.]
|-
|[[User:wuy|Yan Wu]] || X || wuy || ||Framework || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Stephan Wunderlich|| X || sw||||||
|-
|Dehua Xu || || xudehua || xudh || Release || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Kohei Yoshida|| X || kohei||kohei_||[[Calc]] hacker, Calc optimization solver developer||Novell, Inc.
|-
| George Zahopoulos|| X || georgez||||||
|-
| Kurt Zenker|| X || kz||smoketester||RE||Sun Microsystems
|-
|Huajun Zhang || || zhanghuajun|| zhanghj|| SW ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|[[User:Zhangxiaofei|Xiaofei Zhang]]|| || Zhangxiaofei || zhangxiaofei/FelixZ || [[Framework]] ||[[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|Jianwei Zhao || || zhaojianwei || zhaojianwei || Swriter || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Sheng zhao|| X || jacky23 || ||OdfToolKit_odf4j || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Claudio F Filho|| || filhocf||filhocf||Brazilian portuguese Localization||BrOffice.org
|-
| Xiaoyang Yu|| || || ||Disk block reordering||Intel Corporation
|-
| Antonio Xu|| X || antoxu || antoxu || Async dialogs, PRC improvements || Intel Corporation
|-
| Rail Aliev || X || rail || rail || Ru and Tr NL Co-lead || Infra-Resource
|-
| Jeremy Zheng|| X || zhiming || Jeremy || Async dialogs, PRC improvements || Intel Corporation
|-
| [[User:Schmidtm|Matthias Schmidt]] || || schmidtm || schmidtm || Mac OSX Aqua Port || Sun Microsystems
|-
| Yuri Dario || || ydario || Paperino || OS/2 Port || Serenity Systems intl
|-
| Fong Lin || X || pflin || Fong || VBA Interop, Scripting, CJK Enhancement || Novell, Inc.
|-
| [[User:jza|Alexandro Colorado]]|| X || jza || jza|| CL [[OOoES|ES]] ||
|-
| Sunil Amitkumar Janki || || sjanki || sjanki || GNU Linux mipsel porter ||
|-
| [[User:Rescue|Joey Stanford]] || || Rescue/k0fcc || Rinchen || CL [http://eo.openoffice.org/ Esperanto native-lang project] || [http://canonical.com Canonical] ||
|-
| Mingfei Jia || X || jiamingfei || || Lotus Smart Suite filter || IBM Corp.
|-
| Xing Li || X || lixxing || || Accessibility || IBM Corp.
|-
| Wei Guo SHI || X || shiwg || || Accessibility and Smart Suite filter || IBM Corp.
|-
| Takashi Ono || X || tono || || MinGW port || Independent
|-
| Yu Guoqiang|| X || yugq || yugq|| Performance || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Liu YiSong|| || Liu YiSong || Liu YiSong|| PYUNO || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
| Bo Han || X || hanbo || hanbo || VBA Interop || [[Beijing Redflag Chinese 2000 Software Co., Ltd.|Beijing Redflag CH2000]]
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name ||CVS||@openoffice.org || [[IRC Communication]] || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||||sba||||writer||||Sun Microsystems
|-
| Thorsten Bosbach||X||tbo||||framework, testautomation||framework test automation||Sun Microsystems
|-
| Oliver Craemer||X||oc||||[[Calc]], testautomation||calc test automation||Sun Microsystems
|-
| Helge Delfs||X||hde||||testautomation, writer||Test automation||Sun Microsystems
|-
| Fredrik Haegg||X||fha||||writer, testautomation||Writer test automation||Sun Microsystems
|-
| Hasan Ilter||||hi||||writer, printing, pdf export||||Sun Microsystems
|-
| Michael Rüß||||mru||||writer, word im/export||||Sun Microsystems
|-
| Éric Savary||||es||||writer, accessibility||||Sun Microsystems
|-
| [[User:jsi|Joerg Sievers]]||X||jsi||jsi_sun||chart, xml, testautomation||Chart2, XML test automation||Sun Microsystems
|-
| Joerg Skottke||X||jsk||skotti||framework, qa/qatesttool||Framework test automation||Sun Microsystems
|-
| Marc Neumann||X||msc||||database, testautomation||Database access test automation||Sun Microsystems
|-
| Chris Lukasiak||||clu||||database||||Sun Microsystems
|-
| Frank Stecher||||fst||||[[Calc]]||||Sun Microsystems
|-
| Jack Warchold|||| jw||||writer, import/export filters||||Sun Microsystems
|-
| Uwe Luebbers||||ul||||framework||||Sun Microsystems
|-
| Thorsten Martens||||tm||||framework||||Sun Microsystems
|-
| Olaf Felka|||| of||||framework, installation||||Sun Microsystems
|-
| Thomas Klarhoefer||||kla||||chart||||Sun Microsystems
|-
| Wolfram Garten||X|| wg||||draw, impress||draw, impress test automation||Sun Microsystems
|-
| Christian Guenther||||cgu||||draw, impress||||Sun Microsystems
|-
| [[User:Thorsten_Ziehm|Thorsten Ziehm]]||||| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

== Related Pages ==
* [[Commit Rights]]
* [[Contributing Patches]]
* [[User_Experience/Community|User Experience Team]]
* A map of OOo developers around the world is available at http://www.frappr.com/ooodev, please add yourself to the map if you're involved in OOo development. It's just fun to see who's where :-)

[[Category:Development]]
[[Category:Alpha Centauri]]

ODF Toolkit/Minutes/2008 12

2008-12-12T08:59:05Z

Sus: /* 2008/12/12 */

= 2008/12/12 =
{| class="prettytable"
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Let's start..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''AGENDA:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1 Status of the Teams'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''2 Open discussions'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''Dieter_ (n=chatzill@192.18.8.1) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Dieter_,isnick Dieter_]>'''''</div>
| '''''Hi all!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante_afk: hello, i send a mail to you on Monday , do you check it?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Hi MaJun, no sorry I have not seen it, I will come back later to it during discussions..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''no news'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: oh, thank you!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''nothing for now, I have taken several days off.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''The form controls cann't seem to use styles of "Styles and Formatting" yet.so I just defined styles in office:automatic-styles, I'm not sure how to extend the future's use in "Styles and Formatting" yet.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Last Friday I have added a list of tasks to the Wiki, that I personally would like have archieved for a stable 0.7:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| [http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7 http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''With all my optimistic thinking, I see the first 0.7 beta end of January.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''At that time I would like to change ODFDOM from ODF 1.1 to ODF 1.2'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Yeah that is a strange thing does anybody know why OOO doesnt use styles for form controls?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: i asked the dealine of version0.7 in mail, so i know now'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''duyunfen: Not certain if this is possible in ODF 1.2 but a nice feature to enhance the layout of formualrs'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:ok.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''I think they should use styles.so I want to defined the implementation for future's easy extend.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/liuyuhua,isnick liuyuhua]>'''''</div>
| '''''larsb: I need your help , can you have a chat in private.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''duyunfen: Do you know if this is possible in ODF 1.2, you might want to check the latest draft to see if it's possible..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''At least OOo can not do this.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:no,I haven't check the latest draft.But I will.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Thanks, duyunfen!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:thank you!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''<nowiki>;-)</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| ''''':)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''mayjun: If you are interested in the code generation, you might just have a try and if there are questions, just post them on the list, as there might be others who want to join in your effort'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''mayjun: Christian Lippka (who wrote the code generator) and I will assist you and might work on the generator (refaktoring out of the ODFDOM into an own project) at the same time'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Let's start discussions..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: thank you for your suggestion, i will do so'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''MaJun: Thanks for your help!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Anything about odftoolkit someone would like to discuss?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Questions? Remarks?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bei:Why OOo can not do this?Would they not extend this part?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Well the styles and form control topic. Who would be best to talk to to get this feature into OOo?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: First make certain it is in ODF 1.2 :-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''And second, you should ask OOo related questions on [irc://freenode/%23dev.openoffice.org #dev.openoffice.org]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Svante: Sure! But I would like to know who is currently working on form controls'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: Sorry, I don't know'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Soft formatting is such a nice feature of OOo and it´s a pitty it isn´t used for form controls also.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: Remember we are talking about odftoolkit here, not OOo ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''I got one remark from my side regarding the Odftoolkit tasks:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| [http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7 http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''well if we get this into odf 1.2 we would also have to get this into OOo'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bei:I'll check the latest draft.and I will need your help later.then I 'll email to you.:)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Whenever someone is interested, please write to the list and let's discuss topics on the list as long a bugtracker is not enabled..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Anything else?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Than I see you next week!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Have a nice week-end!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Dieter_,isnick Dieter_]>'''''</div>
| '''''bye!'''''

|-
|
| <div align="right">'''<nowiki>|<--</nowiki>'''</div>
| '''''<nowiki>Dieter_ has left freenode ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]")</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bye,Nice week-end too!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''<nowiki>*hmmm* about the warnings item on the list I think a few are there because of the design of odfdom and can only be suppressed by do not show warning annotations.</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Sounds like a design problem, which it is not. It is for instance the recursive function, which has its purpose..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''If you are interested, you are welcome for this task ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''<nowiki>I was taking about the class cast warnings and <T>function(<T>) stuff</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Sorry, not sure what you mean at this moment, but if you see a change to remove the warnings, it would be great if you could give it a try!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''I got to leave as well.. Follow up meeting...'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''see you soon!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''ok bye'''''

|-
|
| <div align="right">'''<nowiki>|<--</nowiki>'''</div>
| '''''Svante has left freenode ("I don't write bugs, I just implement random features!")'''''

|}

= 2008/12/05 =

{| class="prettytable"
|
| <nowiki><Malte></nowiki>
| AGENDA:

|-
|
| <nowiki><Malte></nowiki>
| 1 Status of the Teams

|-
|
| <nowiki><Malte></nowiki>
| 1.1 AODL: Lars (lb)

|-
|
| <nowiki><Malte></nowiki>
| 1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen

|-
|
| <nowiki><Malte></nowiki>
| 2 Open discussions

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><Malte></nowiki>
| 1.1 AODL: Lars (lb)

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>
| no news

|-
|
| <nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>
| .

|-
|
| <nowiki><Malte></nowiki>
| 1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>
| In the last week I'm analyzing the contorl's style and writing some examples,now it beginning to take shape in my mind.now I'm coding it.

|-
|
| <nowiki><Malte></nowiki>
| Sounds good :)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| cool, duyunfen!

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| For my side..

|-
|
| <nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>
| :)thanks.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .. I answered the first time the messages on the forum at the beginning of this week.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| [http://odftoolkit.org/forums http://odftoolkit.org/forums]

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| As I got no mail about the entries I missed them first, now I got an RSS feed on the forum.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Answered the ODFDOM part and fixed the Wiki examples of ODFDOM.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Even did several refactorings on the OdfPackage to make the package example run smooth..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| MaJun: Anything from your side?

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| no,

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| i have no concrete job yet

|-
|
| <nowiki><Malte></nowiki>
| So Svante should give you some concrete task?

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| You may choose one.. ;-)

|-
|
| <nowiki><Malte></nowiki>
| Then offer some ;)

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| that's great, i'd like he can give me some to start

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| ..just work on something that you like (or annoys you, so you would like to change it).. I give you some examples later..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| OK, assuming "later" means via email - anything else to discuss?

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| Svante: thank you

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| You are welcome, MaJun! :-)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| I guess I simply write possible tasks on the list so MaJun and others may take their pick..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| By this it is more 'opensource'.. ;-)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Nothing more from my side..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| ..regarding ODFDOM

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| Better would be putting the possible tasks in the odftoolkit.org wiki...

|-
|
| <nowiki><Malte></nowiki>
| You agree?

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| And write a mail to point on them.. sure that's the best!

|-
|
| <nowiki><Malte></nowiki>
| OK, I think we are done then! :)

|-
|
| <nowiki><Malte></nowiki>
| See you next week...

|}

[[Category:ODFToolkit]]
[[Category:Minutes]]

ODF Toolkit/Minutes/2008 12

2008-12-12T08:58:07Z

Sus: /* 2008/12/05 */

= 2008/12/12 =
{| class="prettytable"
|
| <div align="right">'''<nowiki>[INFO]</nowiki>'''</div>
| '''''Channel view for “[irc://freenode/%23odftoolkit #odftoolkit]” opened.'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''YOU (LogBot_) have joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''''<nowiki>*</nowiki>[irc://freenode/ChanServ,isnick ChanServ]<nowiki>*</nowiki>'''''</div>
| '''''<nowiki>[</nowiki>[irc://freenode/%23odftoolkit #odftoolkit]] Welcome to the ODF Toolkit channel!'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''MaJun (n=MaJun@218.249.75.106) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''-->|'''</div>
| '''''bei (i=rfc821@e177197018.adsl.alicedsl.de) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Hi there!'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''larsb (n=chatzill@192.18.8.1) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Hi,Bernd.'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''Svante (n=sus@192.18.8.1) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''<nowiki>=-=</nowiki>'''</div>
| '''''Svante is now known as Svante_afk'''''

|-
|
| <div align="right">'''<nowiki>=-=</nowiki>'''</div>
| '''''Svante_afk is now known as Svante'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Good morning'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Let's start..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''AGENDA:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1 Status of the Teams'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''2 Open discussions'''''

|-
|
| <div align="right">'''-->|'''</div>
| '''''Dieter_ (n=chatzill@192.18.8.1) has joined [irc://freenode/%23odftoolkit #odftoolkit]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.1 AODL: Lars (lb)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Dieter_,isnick Dieter_]>'''''</div>
| '''''Hi all!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante_afk: hello, i send a mail to you on Monday , do you check it?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Hi MaJun, no sorry I have not seen it, I will come back later to it during discussions..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''no news'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: oh, thank you!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''nothing for now, I have taken several days off.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''The form controls cann't seem to use styles of "Styles and Formatting" yet.so I just defined styles in office:automatic-styles, I'm not sure how to extend the future's use in "Styles and Formatting" yet.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Last Friday I have added a list of tasks to the Wiki, that I personally would like have archieved for a stable 0.7:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| [http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7 http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''With all my optimistic thinking, I see the first 0.7 beta end of January.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''At that time I would like to change ODFDOM from ODF 1.1 to ODF 1.2'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Yeah that is a strange thing does anybody know why OOO doesnt use styles for form controls?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: i asked the dealine of version0.7 in mail, so i know now'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''duyunfen: Not certain if this is possible in ODF 1.2 but a nice feature to enhance the layout of formualrs'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:ok.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''I think they should use styles.so I want to defined the implementation for future's easy extend.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/liuyuhua,isnick liuyuhua]>'''''</div>
| '''''larsb: I need your help , can you have a chat in private.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''duyunfen: Do you know if this is possible in ODF 1.2, you might want to check the latest draft to see if it's possible..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''At least OOo can not do this.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:no,I haven't check the latest draft.But I will.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Thanks, duyunfen!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''Svante:thank you!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''<nowiki>;-)</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| ''''':)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''mayjun: If you are interested in the code generation, you might just have a try and if there are questions, just post them on the list, as there might be others who want to join in your effort'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''mayjun: Christian Lippka (who wrote the code generator) and I will assist you and might work on the generator (refaktoring out of the ODFDOM into an own project) at the same time'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Let's start discussions..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''Svante: thank you for your suggestion, i will do so'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''MaJun: Thanks for your help!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Anything about odftoolkit someone would like to discuss?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Questions? Remarks?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bei:Why OOo can not do this?Would they not extend this part?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Well the styles and form control topic. Who would be best to talk to to get this feature into OOo?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: First make certain it is in ODF 1.2 :-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''And second, you should ask OOo related questions on [irc://freenode/%23dev.openoffice.org #dev.openoffice.org]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Svante: Sure! But I would like to know who is currently working on form controls'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: Sorry, I don't know'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''Soft formatting is such a nice feature of OOo and it´s a pitty it isn´t used for form controls also.'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bei: Remember we are talking about odftoolkit here, not OOo ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''I got one remark from my side regarding the Odftoolkit tasks:'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| [http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7 http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM#ODFDOM_Tasks_to_archive_Version_0.7]

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''well if we get this into odf 1.2 we would also have to get this into OOo'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bei:I'll check the latest draft.and I will need your help later.then I 'll email to you.:)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Whenever someone is interested, please write to the list and let's discuss topics on the list as long a bugtracker is not enabled..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Anything else?'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Than I see you next week!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Have a nice week-end!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Dieter_,isnick Dieter_]>'''''</div>
| '''''bye!'''''

|-
|
| <div align="right">'''<nowiki>|<--</nowiki>'''</div>
| '''''<nowiki>Dieter_ has left freenode ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]")</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>'''''</div>
| '''''bye,Nice week-end too!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''<nowiki>*hmmm* about the warnings item on the list I think a few are there because of the design of odfdom and can only be suppressed by do not show warning annotations.</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Sounds like a design problem, which it is not. It is for instance the recursive function, which has its purpose..'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''If you are interested, you are welcome for this task ;-)'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''<nowiki>I was taking about the class cast warnings and <T>function(<T>) stuff</nowiki>'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''Sorry, not sure what you mean at this moment, but if you see a change to remove the warnings, it would be great if you could give it a try!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''I got to leave as well.. Follow up meeting...'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''see you soon!'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>'''''</div>
| '''''bye'''''

|-
|
| <div align="right">'''''<nowiki><</nowiki>[irc://freenode/bei,isnick bei]>'''''</div>
| '''''ok bye'''''

|-
|
| <div align="right">'''<nowiki>|<--</nowiki>'''</div>
| '''''Svante has left freenode ("I don't write bugs, I just implement random features!")'''''

|}

= 2008/12/05 =

{| class="prettytable"
|
| <nowiki><Malte></nowiki>
| AGENDA:

|-
|
| <nowiki><Malte></nowiki>
| 1 Status of the Teams

|-
|
| <nowiki><Malte></nowiki>
| 1.1 AODL: Lars (lb)

|-
|
| <nowiki><Malte></nowiki>
| 1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen

|-
|
| <nowiki><Malte></nowiki>
| 2 Open discussions

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><Malte></nowiki>
| 1.1 AODL: Lars (lb)

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>
| no news

|-
|
| <nowiki><</nowiki>[irc://freenode/larsb,isnick larsb]>
| .

|-
|
| <nowiki><Malte></nowiki>
| 1.2 ODFDOM/ODF4J: Svante, Christian (cl), MaJun, duyunfen

|-
|
| <nowiki><Malte></nowiki>
| .

|-
|
| <nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>
| In the last week I'm analyzing the contorl's style and writing some examples,now it beginning to take shape in my mind.now I'm coding it.

|-
|
| <nowiki><Malte></nowiki>
| Sounds good :)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| cool, duyunfen!

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| For my side..

|-
|
| <nowiki><</nowiki>[irc://freenode/duyunfen,isnick duyunfen]>
| :)thanks.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .. I answered the first time the messages on the forum at the beginning of this week.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| [http://odftoolkit.org/forums http://odftoolkit.org/forums]

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| As I got no mail about the entries I missed them first, now I got an RSS feed on the forum.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Answered the ODFDOM part and fixed the Wiki examples of ODFDOM.

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Even did several refactorings on the OdfPackage to make the package example run smooth..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| MaJun: Anything from your side?

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| no,

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| i have no concrete job yet

|-
|
| <nowiki><Malte></nowiki>
| So Svante should give you some concrete task?

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| You may choose one.. ;-)

|-
|
| <nowiki><Malte></nowiki>
| Then offer some ;)

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| that's great, i'd like he can give me some to start

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| ..just work on something that you like (or annoys you, so you would like to change it).. I give you some examples later..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| OK, assuming "later" means via email - anything else to discuss?

|-
|
| <nowiki><</nowiki>[irc://freenode/MaJun,isnick MaJun]>
| Svante: thank you

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| You are welcome, MaJun! :-)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| I guess I simply write possible tasks on the list so MaJun and others may take their pick..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| By this it is more 'opensource'.. ;-)

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| Nothing more from my side..

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| ..regarding ODFDOM

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| .

|-
|
| <nowiki><Malte></nowiki>
| Better would be putting the possible tasks in the odftoolkit.org wiki...

|-
|
| <nowiki><Malte></nowiki>
| You agree?

|-
|
| <nowiki><</nowiki>[irc://freenode/Svante,isnick Svante]>
| And write a mail to point on them.. sure that's the best!

|-
|
| <nowiki><Malte></nowiki>
| OK, I think we are done then! :)

|-
|
| <nowiki><Malte></nowiki>
| See you next week...

|}

[[Category:ODFToolkit]]
[[Category:Minutes]]

ODFDOM

2008-12-01T18:11:33Z

Sus: /* Setup ODFDOM build environment */

ODFDOM

2008-12-01T18:11:25Z

Sus: /* Current and Future Work */

ODFDOM

2008-12-01T18:11:17Z

Sus: /* The ODFDOM Layers */

ODFDOM

2008-12-01T18:11:03Z

Sus: /* Overview */

=OpenDocument API - ODFDOM=

ODFDOM has a new home, please visit
http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM

You should register at the ODF Toolkit project and subscribe yourself to the mailing lists of the projects you are interested in.

See you soon,
Svante

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.15 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_15.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-12-01T18:10:49Z

Sus: /* OpenDocument API - ODFDOM */

=OpenDocument API - ODFDOM=

ODFDOM has a new home, please visit
http://odftoolkit.org/projects/odftoolkit/pages/ODFDOM

You should register at the ODF Toolkit project and subscribe yourself to the mailing lists of the projects you are interested in.

See you soon,
Svante

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. A layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.15 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_15.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-09T13:45:47Z

Sus: /* Setup ODFDOM build environment */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. A layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.15 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_15.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-09T13:32:22Z

Sus: /* Current and Future Work */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. A layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.15 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-07T11:40:54Z

Sus: /* Overview */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. A layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-07T11:39:47Z

Sus: /* Setup ODFDOM build environment */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorials] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:14:56Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond <code>org.openoffice.odf.pkg.*</code>

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:10:50Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
Furthermore, the file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:08:33Z

Sus: /* Setup ODFDOM build environment */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your own ODFDOM build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:07:09Z

Sus: /* Current and Future Work */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You might also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the ODF toolkit project.

=Setup ODFDOM build environment =

To establish your build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:06:10Z

Sus: /* Setup ODFDOM build environment */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

To establish your build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM source bundle and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work solely with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track the changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:03:36Z

Sus: /* Setup ODFDOM build environment */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

To establish your build environment:

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T13:02:52Z

Sus: /* Current and Future Work */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version 0.6.14 and its reference implementation based on Java 5.
ODFDOM is currently provided with an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads]. An online Mercurial repository is planed.

In contrary to its predecessor [[Odf4j]] ODFDOM has version number. The future version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources of the Java reference implementation.

The development is being discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:56:26Z

Sus: /* The ODF Typed DOM / XML Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond <code>org.openoffice.odf.dom.*</code>

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:55:49Z

Sus: /* The ODF Document / Convenient Functionality Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is to provide a higher usability for the API user.
To establish this a convenient layer class usually controls multiple XML elements representing a component. In contrary to this the classes from the previous XML layer only control their ODF element and its attributes.

For instance, the table class of the convenient layer manipulates not only the table element and its attributes, but may manipulate all table element children.
For example, when adding a cell to a table not only a new table cell would be created, but as well row and column information on their elements might be updated. All this in a single method call at the table.

Usually a class from the Convenient Layer is derived from the covered XML layered class to inherit its DOM functionality.

As naming convention all sources of the ODF document / convenient functionality layer are organized beyond <code>org.openoffice.odf.doc.*</code>
The name of a convenient class is similar as it's parent from the XML layer, only the suffix 'Element' has been neglected.
For example, the convenient class for a 'draw:frame' element would be represented in the ODFDOM Java reference implemenation as <code>org.openoffice.odf.doc.draw.OdfFrame</code> class.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:33:26Z

Sus: /* The ODF Typed DOM / XML Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the <code>OdfFrame</code> class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class <code>org.openoffice.odf.dom.draw.OdfFrameElement</code>.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph' for usability reasons.

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:32:06Z

Sus: /* The ODF Typed DOM / XML Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the OdfFrame class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class 'org.openoffice.odf.dom.draw.OdfFrameElement'

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:31:45Z

Sus: /* The ODF Typed DOM / XML Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the [http://www.w3.org/DOM/ W3C DOM API], but only the ODF standardized XML file streams of the document (e.g. content.xml, meta.xml) have their own classes representing their ODF XML elements. Foreign XML within a specified ODF XML file will remain in the document model in general and won't be neglected unless desired ( which still might be a future option).

Example of the ODF XML representing a table in ODF:

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument standard the ODF elements are reused among all document types. The above XML of a table is for instance equally usable in Text and Spreadsheet documents.

This XML would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

The sources for the ODF elements are all generated from the ODF grammar (RelaxNG schema) using the following naming conventions in the Java reference implementation:
* The class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix (e.g. the 'draw:frame' element has the OdfFrame class).
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo. Therefore the frame element 'draw:frame' would be generated in Java as class
'org.openoffice.odf.dom.draw.OdfFrameElement'

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are still not part of the v0.6.x releases
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:19:14Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myVacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:18:59Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

For instance, an ODF text document like 'myvacation.odt' might contain the following files:

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:17:52Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level a document is represented by a bundle of named resources zipped to a package.

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:17:24Z

Sus: /* The ODF Package / Physical Layer */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level, a document is represented as a bundle of named resources zipped to a package.

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the '/Pictures' directory and its content are specified by the ODF standard.
The file streams are similar for all types of ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (similar to an inventory)
* Begin the package with an unzipped 'mimetype' file stream (allowing others to easily identify the package)

All sources of the Package/Physical layer are organized in ODFDOM beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(although not shown by an ODF application (like OOo), as not used by the shown content):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:11:05Z

Sus: /* OpenDocument API - ODFDOM */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level, a document is represented as a package of named resources. For standardized file streams explicit methods are being provided.

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the /Pictures directory and its content are specified by the ODF standard.
The file streams are similar for all ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (otherwise OOo won't save the file streams)
* Begin the package with an unzipped 'mimetype' file stream

All sources of the Package/Physical layer are organized beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(not shown by OOo, as not referenced by content.xml):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]

ODFDOM

2008-10-06T12:08:12Z

Sus: /* Overview */

=OpenDocument API - ODFDOM=

ODFDOM is the name of the new free OpenDocument framework sponsored by Sun Microsystems Inc.

It's purpose is to provide an easy common way to create, access and manipulate OpenDocument files, without requiring detailed knowledge of the OpenDocument specification.

It is the successor of [[AODL]] and [[Odf4j]], designed together with their architects to provide the ODF developer community an easy lightwork programming API, meant to be portable to any object-oriented language.

The Java 5 reference implementation of ODFDOM is available under LGPL3 since May 2008 together with its [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online JavaDoc API].
<br>
<br>

=Overview=

The ODFDOM project's objective is to provide an easy API for reading, writing and manipulating documents of the OpenDocument format (ODF).
To archive this, the ODFDOM API follows a layered approach to access documents. This layered design is the robust foundation for a well-designed structure like modularity.

Overview over ODFDOM layers:
* The bottom ODF Package / Physical Layer - provides direct access to the resources stored in the ODF package, such as XML streams, images or embedded objects.
* The ODF Typed DOM / XML Layer - represents the ODF XML elements from the standardized ODF XML streams (e.g. content.xml, styles.xml). This layer is based on the platform and language independent [http://www.w3.org/DOM/ DOM API standardized by the W3C], best-known by its implementation through every browser. Following the DOM concept the layer provides a class for every ODF XML element defined by the ODF specification and its grammar (the RelaxNG schema). But instead of laboriously writing all these classes, they are being generated directly from the ODF grammar. This generation guarantees complete and accurate coverage of the ODF specification on one side and an easy upgrade to future ODF specifications on the other.
* The ODF Document / Convenient Layer - is concerned with usability aids. The layer represents manipulating components consisting of multiple underlying ODF XML elements. The API for these manipulations is not specified by the ODF standard. In fact the API is given by frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2').
* The Customized ODF Document / Extendable Layer - is concerned with user defined customizations. Although this level is not being delivered as part of the library, the level is listed as it is still part of the overall design. The level describes the sources from a ODFDOM user overwriting ODFDOM functionality (e.g. all new tables will have a certain default size and color).<br>

<center> [[Image:ODFDOM-Layered-Model.png]]

<br>

ODFDOM is part of the [http://odftoolkit.openoffice.org odftoolkit project]. Development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list].

<br>

</center>

=The ODFDOM Layers=

==The ODF Package / Physical Layer==

At this level, a document is represented as a package of named resources. For standardized file streams explicit methods are being provided.

[[Image:ODF_Package.jpg]]

'''Note:'''
All file streams aside of the /Pictures directory and its content are specified by the ODF standard.
The file streams are similar for all ODF documents.

The main requirements for this layer are:
* Zip/unzip the file streams of the package
* Enlist all file streams in the /META-INF/manifest.xml (otherwise OOo won't save the file streams)
* Begin the package with an unzipped 'mimetype' file stream

All sources of the Package/Physical layer are organized beyond org.openoffice.odf.pkg.*

The following example illustrates how to add a graphic to the package level
(not shown by OOo, as not referenced by content.xml):
<pre>
import org.openoffice.odf.pkg.OdfPackage;
[...]

// loads the ODF document package from the path
OdfPackage pkg = OdfPackage.load("/home/myDocuments/myVacation.odt");

// loads the image from the URL and inserts the image in the package, adapting the manifest
pkg.insert("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Typed DOM / XML Layer==

At this level, all XML file streams of the document are accessible via the W3C DOM API, but only the ODF standardized XML file streams of the document their own classes representing their ODF XML. Foreign XML within a specified ODF file remains in general in the document model and won't be neglected unless desired ( which might be a future option).

For instance the XML of an ODF table

[[Image:fruitTable_code.jpg]]

'''Note:''' In the OpenDocument ISO standard the ODF elements are reused among all document types. The above XML for a table is equally usable in Text and Spreadsheet documents.

Would be mapped to a W3C derived ODF DOM class structure:

[[Image:table_fruits_diagramm.jpg]]

All sources of the typed DOM/XML layer are organized beyond org.openoffice.odf.dom.*

Its sources are all generated from the ODF RelaxNG schema using the following naming conventions:
* The Class name is equal to the element local name using 'Odf' as an Prefix and 'Element' as Suffix.
* Elements are stored beyond a sub-package equal to their Namespace used by the OOo.

'''Note:''' The element local names 'h' and 'p' have been renamed to the classes 'Heading' and 'Paragraph'

For instance, the frame element 'draw:frame' would be generated as class
org.openoffice.odf.dom.draw.OdfFrameElement

'''Note:''' Java dependent helper classes, which are not part of the official API, but for convenient part of the module are delivered beyond org.openoffice.odf.java.*

The following example illustrates how to add a graphic to the ODF document, that it is viewable:
<pre>
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;
import org.openoffice.odf.doc.OdfDocument;
import org.openoffice.odf.dom.element.text.OdfParagraphElement;
import org.openoffice.odf.dom.OdfNamespace;
import org.w3c.dom.Document;
[...]

// loads the ODF document from the path
OdfDocument odfDoc = OdfDocument.load("/home/myDocuments/myVacation.odt");

// get the ODF content as DOM tree representation
Document odfContent = odfDocument.getContent();

// XPath initialization ''(JDK5 functionality)''
XPath xpath = XPathFactory.newInstance().newXPath();
xpath.setNamespaceContext(new OdfNamespace());

// receiving the first paragraph "//text:p[1]" ''(JDK5 functionality)''
OdfParagraphElement para = (OdfParagraphElement) xpath.evaluate("//text:p[1]", odfContent, XPathConstants.NODE);

// adding an image - expecting the user to know that
// an image consists always of a 'draw:image' and a 'draw:frame' parent
// NOTE: Child access methods are not part of the first v0.6 release
para.createDrawFrame().createDrawImage("/myweb.org/images/myHoliday.png", "/Pictures/myHoliday.png");
</pre>

<br>

==The ODF Document / Convenient Functionality Layer==

The purpose of a class from the convenient layer is a higher usability for the API user. Usually a class is derived from covered XML layered class.

All sources of the ODF document / convenient functionality layer are organized beyond org.openoffice.odf.doc.*
The name of a convenient class is similar as it's XML parent, only the suffix 'Element' has been neglected.

For instance, a convenient class for a frame, derived from the class representing 'draw:frame' would be named
org.openoffice.odf.doc.draw.OdfFrame

In contrary to the classes of the XML layer, an object of the convenient layer controls multiple XML elements.
For instance, a default table consisting of the similar amount of the earlier mentioned table can be created by a single method call, instead creating every single element using directly the XML layer.

<br>

==The Customized ODF Document / Extendable Layer==
Although not part of the ODFDOM package it is designed as a layer on top of ODFDOM, where customer are able to replace/overwrite/customize ODF elements.

For instance, change the default size/style of their new tables.

<br>

=Current and Future Work=

The current ODFDOM version is 0.6.14, offering you an [http://odftoolkit.openoffice.org/nonav/odfdom/javadoc/ online API] and [http://odftoolkit.openoffice.org/servlets/ProjectDocumentList?folderID=759&expandFolder=759&folderID=0 several downloads].
ODFDOM is based on Java 5.

In contrary to its predecessor [[Odf4j]] ODFDOM is versioned. The version 1.0 will represent a stable API not necessarily a complete API.

Especially the convenient layer will grow on demand and surely will profit from the work done in Odf4j and the experience of the OOo API.

As ODFDOM should be the basement of many future ODF projects, a high quality is desired. Therefore automatic tests are obligatory for all new sources.

Further development is discussed on the [http://odftoolkit.openoffice.org/servlets/SummarizeList?listName=dev dev@odftoolkit.openoffice.org mailing list] - subscribe by sending an empty message to [mailto:dev-subscribe@odftoolkit.openoffice.org dev-subscribe@odftoolkit.openoffice.org].

Anybody who is interested to get more information and/or have a real-time discussion is invited to
participate in our weekly IRC meeting every Friday at 9.30 AM (CEST or UTC+2 hours) on irc://freenode/#odftoolkit . You can also [http://odftoolkit.openoffice.org/servlets/ProjectMemberList join] the project.

=Setup ODFDOM build environment =

1.) Install [http://java.sun.com/javase/downloads/index_jdk5.jsp Java / JDK 5]

2.) Install [http://netbeans.org NetBeans 6.1]

3.) Install [http://mercurial.berkwood.com Mercurial 1.x]

Setup Mercurial
Windows: <Hg Install Dir>\Mercurial.ini or Unix: <Hg Install Dir>/.hgrc
[ui]
username = foo@bar.com

4.) Get [http://odftoolkit.openoffice.org/files/documents/254/4238/odfdom-src-v0_6_14.zip ODFDOM]

Unpack the ODFDOM package and start Netbeans. Open an existing project in Netbeans and choose the unpacked ODFDOM directory.
As the ODFDOM source bundle comes together with Netbeans project files, ODFDOM opens as a preconfigured project.
You still got the opportunity to work with [http://ant.apache.org/ ANT] directly on the command line instead having the IDE GUI comfort provided by Netbeans.

[http://www.selenic.com/mercurial/wiki/ Mercurial] is being used as distributed revision control.
Since Netbeans 6.1 the [http://wiki.netbeans.org/MercurialVersionControl Mercurial plugin] is part of the IDE, which help you to track changes being made and ease providing patches.

In case you are new to Netbeans, there are several nice [http://platform.netbeans.org/tutorials/ Netbeans tutorial] available.

--[[User:Sus|Svante]] 00:33, 24 April 2008 (CEST)

[[Category:ODF]]
[[Category:ODFToolkit]]
[[Category:Effort]]