OpenDocument v1.2

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Dear TC members,

after OpenDocument v1.1 has been approved as a Committee Specification, 
we can concentrate on OpenDocument v1.2 now. There are a couple of items 
that we may want to discuss in our coordination call next Monday:

1. The divison of the specification into several parts, as discussed in 
the work call last Monday. What we have discussed there is to make the 
formula specification a separate specification. I further would like to 
propose that we do the same for the package specification that currently 
is chapter 17 of the OpenDocument specification, but has no references 
to the remaining specification.

The division of the specification into the three parts packages, core 
and formulas actually would allow us to advance the three parts 
independent of each other. We have to work on the details, but my 
assumption is that it in particular would allow us to conduct public 
reviews and standardization ballots for the three parts independent of 
each other.

2. The schedule. We have discussed a possible schedule in the work call 
last Monday. Based on this discussions, I would like to propose the 
following, more detailed schedule:

now - 31.1.07: Discussion/Approval/Integration of enhancements
1.2-31.3.07: Editing/Internal Reviews of the specification/Last Minute
              Changes
1.4-30.4.07: Committee Draft approval/Last Minute Changes
1.5-30.6.07: Public Review
1.7-31.8.07: Processing of Feedback/Committee Specification Ballot
1.9-30.9.07: OASIS Standard Ballot

This schedule is based on the assumptions that the months June, July and 
August are holiday months and therefore not very suitable for OASIS 
standard ballots (I have checked when the ballots for existing standards 
took place. None took place in June/July, and only very few in August).

If we divide the specification into three parts, then this schedule 
applies to the core and package parts. The formula part actually may 
follow an earlier schedule.

3. The scope. We have already agreed that we include meta data, 
accessibility enhancements and formulas into the specification. Because 
we restricted the changes for OpenDocument 1.1 to a minimum, I think it 
will be required to allow other enhancements as well, so that 
OpenDocument keeps up to date with the requirements of applications that 
implement it. I therefore propose that we tend to include further 
proposals for enhancements if
- they do not break the compatibility with OpenDocument 1.1, and if
- we find a TC member for each of the individual proposals who is 
advancing the proposal to state there we can agree on it an can include 
it directly into the specification (what requires a schema and 
descriptions), and if
- we can assume that the proposal gets implemented.

Best regards

Michael

-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS