RE: [office] ODF 1.2 Table-Protected Proposal

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

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.

[ ... ]