OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] ODF 1.2 Items


Hi Florian,

I'm replying to this mail rather than to the mail you have send out a 
few minutes ago because this one contains the actual list of items. In 
this other mail you've said:

>> formal requirements we have agreed (among
>> them was adding a formal proposal to the Wiki for all items that are
>> proposals)
> 
> Thats not my understanding. My understanding from the last call was that the item needed to be in the list and a proposal needed to be ready ASAP --- but it was not a requirement to be able to be discussed.

What we have agreed is (according to minutes)

> TC members unanimously agreed to the following principles:
> 
> 1) For existing, open ODF 1.2 proposals, if a TC member feels that the 
> proposal is a "must have" item for ODF 1.2, then he should add a link to 
> it on the wiki here: 
> http://wiki.oasis-open.org/office/OpenDocument_v1.2_tasks
> 
> 2) If their are remaining features which TC members feel must be in ODF 
> 1.2, but which are not yet entered as formal proposals, then the member 
> should enter a new proposal according to the instructions here: 
> http://wiki.oasis-open.org/office/How_to_propose_a_change_or_addition_to_ODF 
> and then indicate it is a must have item by adding it to the table 
> according to #1, above.
> 
> TC members are asked to complete both items above November 30th 2008.

For many of your proposals below, no formal proposals do exist (even 
none that are incomplete), and where proposals seem to exist, you did 
not enter a link to the Wiki as agreed. So, you unfortunately missed 
both of the above principles. Please note further that we have agreed on 
a standing rule for proposals some time ago. Which means that unless 
otherwise stated, we consider only proposals that have been entered into 
the Wiki as a proposals.

Anyway, since the list of items that have been proposed for ODF 1.2 has 
become very long, I'm proposing that we move all proposals that we can 
move to the next ODF version without breaking OASIS processes to the 
next version, or agree on a deadline where proposals have to be 
accepted, rather than to be proposed. This would effect items for which 
(formal) proposals do exist the same way as yours, so that it would not 
matter whether or not there is a formal proposal existing today.

Best regards

Michael

BTW: With one exception, you did not enter you name into the 
"Responsible" columns. We have not specifically discussed this, but it 
should be clear that unless an item is required by the OASIS process, it 
is the TC member that is suggesting an item who is responsible for its 
completion. So, regardless whether we include these items into ODF 1.2, 
can I assume that you feel responsible for them?


On 11/30/08 22:39, Florian Reuter wrote:
> Hi,
> 
> added the following items to the wiki:
> 
> Standardize the compatiblity options important for interop. Additionally 
> add text which suggest that implementers submit the compat options they use.
> Standardize form control types like "com.sun.star.*"
> Clarify whether normalization in input-fields applies or not.
> Clarify meaing of style:dynamic-spacing.
> Add optional attribute which allows to write out the position relative 
> to the page of objects for interop.
> Submit "page-anchoring" to accessiblity SC.
> Depricate "sub-tables".
> Specify "Star-View-Metafiles" or discourage their use.
> Add a "page-break" element similar to a "soft-page-break".
> Write out default values.
> Support odd-page, even-page and auto as an attribute of fo:break-before 
> and fo:break-after.
> Clarify how master-page-break and fo:break-before resp. fo:break:after 
> interact.
> Clarify what master-page-break="" means.
> Specify how to distinguish between shapes and text-boxes.
> Discourage use of "next-page-style". Instead add "style:header-first" 
> similar to "style:header-left"
> *Forbid* the use of the generator-id. Instead force implementors to use 
> a compatiblity option at least.
> Add "field-marks" or a similar mechanism.
> Grouping for radio-buttons.
> Clarify how fit-to-size and "nn" interact.
> Allow anonymous master-pages.
> 
> ~Florian
> 


-- 
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

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]