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: ODF 1.2 Handling of Deprecated Features - Suggested Approach


I notice in the Table-Protected proposal
(http://wiki.oasis-open.org/office/Table-Protected) and in other
discussions, there is discussion of deprecating certain features (sometimes
normative bugs) of ODF 1.0/1.1.

It seems valuable to create a non-normative Appendix to ODF 1.2 parts where
there are any deprecated elements.  This Appendix could 

 - identify all deprecated features (so they can be found in one place), 
 - provide a simple rationale/explanation, 
 - provide a suggestion for how implementations might make transition away
from the deprecated feature
 - indicate the earliest that the deprecated feature might be removed from
ODF (I suggest that should be a 2.0, not a 1.x).  

How's that for an approach?

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Friday, December 12, 2008 22:52
To: 'OpenDocument Mailing List'
Cc: Michael.Brauer@Sun.COM
Subject: RE: [office] ODF 1.2 Table-Protected Proposal


I have a few observations about the current proposal at
http://wiki.oasis-open.org/office/Table-Protected (2008-12-10 edit).

I think we need to take this one on very carefully.  We certainly need more
understanding of the impacts on current implementations and the consequences
of any selected approach.

[ ... ]

B.7. A third remedy, in this situation, would be to allow either attribute
naming (with the ODF 1.2 schema providing the choice) and to require that
when a table:protect is seen to occur, it should be preserved and that
newly-created table cell protection attributes should be table:protect if
any of those have occured and table: protected otherwise.  This is a clumsy
and incomplete approach and it does nothing for saving documents down-level
(where apparently an implementation should do whatever it has already been

B.8 It occured to me that another action would be to deprecate the attribute
by any spelling, allowing the style:cell-protect to do its magic.  Not that
pleasant, I'm sure, but serves to indicate there are more alternatives to
consider and put in the balance.

[ ... ]

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