[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]