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