[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] ODF 1.2 Table-Protected Proposal
In that case, my recommendation is as follows: 1. The schema for the <table:cell> case be revised to allow a choice of <table:protect> and <table:protected>. 2. The normative text explain what the significance of this attribute is, in either form, with respect to the <table:table> attribute, the optional digest of the key, and the style:cell-protect style. In particular, what is the effect of style:cell-protect if set for the same <table:cell>. 3. One of the forms be declared to be deprecated in the normative text. You choose. 4. A non-normative appendix on deprecation guidelines include a brief rationale for the deprecation (and the choice) along with a recommendation of processor behavior that will have the least down-level impact, work with processors that support multiple versions of ODF 1.0/1.1/1.2, and that provide a way to eliminate the production of the deprecated attribute by the time it is restricted entirely (e.g., not before ODF 2.0). - Dennis -----Original Message----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] http://lists.oasis-open.org/archives/office/200812/msg00130.html Sent: Monday, December 15, 2008 01:55 To: dennis.hamilton@acm.org Cc: 'OpenDocument Mailing List' Subject: Re: [office] ODF 1.2 Table-Protected Proposal Dennis, you are right that my proposal resolves a defect. But the resolution of the defect may have an impact on existing applications, depending on whether their implementors took the schema as being correct or the description. For that reason, I think it is very reasonable to resolve this through a formal proposal and a formal decision by the TC. Please note that this case differs from previous cases where we corrected spelling errors in the schema that where clearly identifiable as spelling errors, like a "right" that was spelled "rihgt". There are of cause alternatives how the inconsistency can be checked, but I believe the current proposal is in so far balanced as it considered backward compatibility but also provides a consistent naming of attributes for the future. Best regards Michael On 13.12.08 07:51, Dennis E. Hamilton wrote: http://lists.oasis-open.org/archives/office/200812/msg00116.html > Michael, > > 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. > > A. DEFECT REPORT, NOT FEATURE REQUEST > > I believe this is a defect report against the ODF 1.2 part 1 draft as well > as the OASIS ODF 1.0 Standard, the ISO/IEC International Standard 26300:2006 > for ODF 1.0 (and our OpenDocument-v1.0ed2-cs1 with the same substantive > content) and the OASIS ODF 1.1 Standard. As such, I don't think this should > be counted as a proposal for ODF 1.2 and there should be no problem with > discussion of this report and its recommendation under the standing rules as > amended last week. > [ ... ] > > 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 > doing). > [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]