Re: [office] ODF 1.2 Table-Protected Proposal

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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:
> 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. ALTERNATIVES NEED TO BE CONSIDERED
> 
> B.1. In all of the published ODF Standards and in the latest draft for ODF
> 1.2 part 1 (OpenDocument-v1.2-draft7-12.odt), including the separate schemas
> and the in-line schemas (which I take to be normative), the <table:cell> and
> <table:covered-cell> elements have a table:protect attribute that specifies
> cell protection.  Prior to ODF 1.2, the text mentions table:protected
> instead, while also asserting that this attribute is unrelated to the
> table:protected and style:cell-protect attributes described in section 8.1.1
> (on <table:table>).
> 
> B.2. One way to resolve the discrepancy is to consider it to be an editorial
> error in the text for <table:cell> and <table:covered-cell> in the existing
> standards that is now corrected in the latest draft(s) of ODF 1.2 part 1.
> 
> B.3. The other way to resolve the discrepancy is to say that the text is
> correct and the schemas are incorrect in all previous specifications and in
> all drafts of ODF 1.2 (and the separate schemas which are all that we have
> in the case of 1.2). 
> 
> B.4. I only know of one occasion where we have changed a schema rather than
> the text, and that was done only after being careful to determine that no
> implementation would be impacted.  I assume that was due, in part, to
> recognizing that it was the in-line schema that is understood to be
> normative.
> 
> B.5. In the absence of any other information, I would expect that it is more
> appropriate to apply remedy (B.2) rather than remedy (B.3).  
> 
> B.6. Is it the case that there are known to be substantial implementations
> of ODF 1.0 and ODF 1.1 that use table:protected under <table:cell> and
> <table:covered-cell> elements and neither use nor accept table:protect, even
> though that is specified in the in-line schemas as well as the standalone
> schemas?
> 
> 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).
> 
> 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.
> 
> 
>  
>  - Dennis
> 
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability 
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 
> 
> 
> 
> 
> ANALYSIS
> 
> 1. OASIS ODF 1.0 Standard Review
> 
> There are several mentions of table:protected in the text of ODF 1.0.  One
> should be table:protect in order to match the one schema introduction of a
> table:protect attribute (1.3-1.4, below).
>  
> 1.1 In the OASIS ODF 1.0 Standard, OpenDocument-v1.0-os.pdf, section 8.1.1
> Table Element, Protected heading (pp.178-179), I notice that the attribute
> name spellings table:protected and table:protection-key are used
> consistently in the description of the feature and in the in-line schema
> text (lines 3573-3584).  OpenDocument-schema-v1.0-os.rng lines 3573-3584
> agree.
> 
> 1.2 Under the same heading, it is also stated, "If a table is protected, all
> of the table elements and the cell elements with a style:cell-protect
> attribute set to true are protected."
> 
> 1.3 Section 8.1.3 Table Cell (p.181) specifies the <table:cell> and
> <table:covered-cell> elements.  Under the Table Cell Protection heading
> (p.186), both elements have optional table-cell protection.  The text is
> "The *table:protected* attribute protects the table cells. Users can not
> edit the content of a cell that is marked as protected.  This attribute is
> not related to the table:protected attribute for table elements (see section
> 8.1.1) and the table:cell-protect attribute for table cell styles (see
> section 15.11.14)."  There is no table:cell-protect attribute.  It should
> mention style:cell-protect attribute the same as section 8.1.1 (see 1.1,
> above); this is entirely an editorial matter since the point is that
> style:cell-protect is "not related."  It is also not clear what this feature
> is related to if not that, and why.
> 
> 1.4 What *is* clear is that in the in-line schema fragment (lines
> 3732-3738), the attribute name is *table:protect*, not table:protected as
> used in the text.  OpenDocument-schema-v1.0-os.rng lines 3732-3738 agree.
> 
> 1.5 Section 8.3.3 Scenario Tables specifies the special element
> <table:table-scenario> that causes the table to be a scenario table (p.197).
> Under the Protected heading (p.199), there is another table:protected
> attribute where, "The table:protected attribute specifies whether or not the
> data that is displayed within the scenario is protected from being edited.
> The attribute is only evaluated if the table on which the scenario displayed
> is also protected (see section 8.1.1)."  Here the in-line schema fragment
> (lines 3970-3976) uses table:protected, the same as in the description of
> the feature.  OpenDocument-schema-v1.0-os.rng lines 3969-3975 agree.
> 
> 1.6 There are no other occurrences of table:protect and table:protected in
> the OASIS ODF 1.0 Standard.  There is an additional occurrence of
> table:protection-key in section 8.5.1, Document Protection, related to
> structure protection of spreadsheet tables.
> 
> 1.7 Section 15.11.14 Cell Protect defines the style:cell-protect attribute,
> the only :cell-protect attribute in ODF 1.0.  'This attribute is only
> evaluated if the current table is protected (see section 8.1.1). The value
> of the attribute can be "none", "hidden-and-protected", or a space-separated
> list containing the values "protected" or "formula-hidden".'  The in-line
> schema fragment (lines 15487-15504) agrees.  OpenDocument-schema-v1.0-os.rng
> lines 15482-15499 correspond.
> 
> 2. ISO/IEC International Standard 26300:2006 for ODF 1.0.
> 
> Apart from pagination differences, the content of
> OpenDocument-v1.0ed2-cs1.pdf sections involving table:protect and
> table:protected corresponds to that of the OASIS ODF 1.0 Standard.  The
> editorial defect in the text of section 8.1.3 Table Cell under Table Cell
> Protection (now p.188) is the same.  There is no separate schema file
> provided with IS 26300.
> 
> 3. OASIS ODF 1.1 Standard
> 
> Apart from pagination difference, the content of OpenDocument-v1.1-os.pdf
> sections involving table:protect and table:protected corresponds to that of
> the OASIS ODF 1.0 Standard.  The editorial defect in the text of section
> 8.1.3 Table Cell under Table Cell Protection (now p.193) is the same.
> OpenDocument-schema-v1.1-os.xml corresponds to
> OpenDocument-schema-v1.0-os.rng in this respect.
> 
> 4. OpenDocument-v1.2-draft7-12.odt and OpenDocument-v1.2-draft7-schema.rng
> (dated 2008-07-18)
> 
> 4.1 Here, table:protection-key-digest-algorithm is added (with default SHA1)
> in conjunction with table:protection-key.  That's good.  This may be where I
> had seen discussion of this at some point.
> 
> 4.2 The schema still has table:protect exactly where earlier schemas have
> (for <table:cell> and <table:covered-cell> elements.  table:protected is
> used in all other places, the same as for all previous versions of ODF
> standards.
> 
> 4.3 In the document, the description of <table:cell> and
> <table:covered-cell> now agrees with the schema, referring to the
> table:protect attribute in section 18.1049.  table:protected is used in all
> other cases.
> 
> 4.4 In section 18.1049 on table:protect (p.597), the description is now,
> "The table:protect attribute specifies whether or not a table cell is
> protected. Users can not edit the content of a cell that is marked as
> protected.  The default value for this attribute is false."  Note that the
> additional explanation about being separate from the use of table:protected
> and style:cell-protect is no longer provided.
> 
> 4.5 In section 18.1050, table:protected is described (p.597).  The
> individual occurrences are each defined.
> 
> 4.5.1 For table:protected in <table:scenario>, section 18.1050.2, the text
> is "The table:protected attribute specifies whether or not the data that is
> displayed within the scenario is protected from being edited. The attribute
> is only evaluated if the table on which the scenario displayed is also
> protected." (Compare with 1.5, above.  The only difference is removal of the
> reference to the <table:table> Table Element section.)
> 
> 4.5.2 For table:protected in <table:table>, section 18.1050.3, the text is
> "The table:protected attribute specifies whether or not a table is protected
> from editing. If the table is protected, the table:protection-key attribute
> can specify a password to prevent a user from resetting the protection flag
> to enable editing. If a table is protected, all of the table elements and
> the cell elements with a style:cell-protect attribute set to true are
> protected.  To avoid saving the password directly into the XML file, only a
> hash value of the password is stored within the table:protection-key
> attribute."  This corresponds with the section 8.1.1 description in the
> existing standards for ODF.
> 
> 4.6 It appears that the only material change (beside the welcome provision
> of table:protection-key-digest-algorithm) is that there is no text that
> mentions table:protected in conjunction with the <table:cell> and
> <table:covered-cell> elements.  table:protect is used in agreement with the
> schema.
> 
> 
> 
> 
> 
> SIDE OBSERVATIONS
> 
> It is odd that the <table:table> element's table:protected and
> table:protection-key are independently optional, according to the schema,
> with the default value table:protected="false".  The effect of
> table:protection-key being present is defined only for the case that
> table:protected="true".  
> 
> I also don't know where the hashing algorithm and the encoding of the result
> is defined for creation of the table:protection-key value.  There is also no
> additional explanation for the use of the key with table:structure-protected
> in spreadsheets (section 8.5.1, Document Protection).  It is clear that the
> only thing the key does is prevent disclosure of someone's chosen key.
> Likewise, the ODF 1.2 table:protection-key-digest-algorithm attribute can be
> swapped or deleted.  A known key's hash can be easily substituted, or the
> table:protection-key attribute can simply be deleted from the file.  Since
> the key will not prevent a determined party from being able to edit
> protected cells, the only meaningful protection is if the subfile is
> digitally signed using PKI methodology.  It might be useful to speak to the
> level of security that this mechanism provides for changes to the document
> versus protection of the unknown key that has a particular hash.
> 
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> http://lists.oasis-open.org/archives/office/200812/msg00082.html
> Sent: Wednesday, December 10, 2008 03:56
> To: OpenDocument Mailing List
> Subject: [office] My single ODF 1.2 proposal
> 
> Dear TC members,
> 
> the only proposal that I have and that I wish to be included into ODF 1.2 is
> 
> http://wiki.oasis-open.org/office/Table-Protected
> 
> It actually just resolves an ambiguity we have in ODF 1.1 between the 
> text and the schema. The proposal contains the necessary background. I 
> believe it is non controversial, and its discussion will take us less 
> than 5 minutes.
> 
> [ ... ]
> 


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