RE: [office] ODF 1.2 Table-Protected Proposal

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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).
> 
[ ... ]