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

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


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


On 13.12.08 07:51, Dennis E. Hamilton wrote:
> 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
> understanding of the impacts on current implementations and the
> of any selected approach.
> 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
> 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
> 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
> 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
> and incomplete approach and it does nothing for saving documents
> (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]