[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Review of CD01 Rev 4
Hi Patrick, all, I have reviewed the marked changes of CD01 Rev04. There is an impressive number of changes, and I believe this draft takes us a large step further to a public review draft. Below are my comments to the changes. Most of them actually are just small editorial issues. Best regards Michael 2.2.1 reads now: "This defines two methods of document representation:" It seems that we don't say what "this" is now. 2.16.3: "An automatic style is one contains formatting" should read "An automatic style is one *that* contains formatting" 6.3.1: "OpenDocument fields" should read "Document fields", because what is said in this section applies only to document fields. 6.4.1: "The value of a sequence variable is initialized to 0 (zero) by its declaration. " should be indented 6.7.10: maco -> macro 7.1: "text:id" is not formatted with the "Attribute" style. 8.1: I agree that eliminating terms like "similar" is reasonable, but I'm wondering whether we should anyway keep the information that the ODF tables use the same underlying model as HTML tables, because this may help to understand the specification. What about adding a note after the first paragraph: "Note: This table model basically equals that of HTML and XSL." I'm further wondering whether we should keep the paragraphs that explain how tables are displayed in text documents and spreadsheets. Suggestion: "Table rows may be empty, and rows within the same table may contain a different number of table cells. Note: Spreadsheet applications often operate on large tables that have a fixed implementation dependent row and column number. To save space, implementations may only store the area of the table that contains data, formatting or any other kind of information. When loading a table with empty or incomplete rows into a spreadsheet application, empty rows may result in rows containing only empty cells. Incomplete rows may be filled with empty cells. In contrast to spreadsheets, the number of rows and columns of tables in text documents and presentations often differs from table to table. Incomplete rows are basically rendered as if they had the necessary number of empty cells, and the same applies to empty rows. Empty cells often occupy the space of an empty paragraph." 8.1.3: It's not new in this draft, but the sentence "This element must not appear in a <table:covered-table-cell> 8.1.4" seems not be required, because the schema forbids this already. What I'm wondering is whether we either there or in 8.1.4 should explain a little bit more what the relation between this element and <table:covered-table-cell> is. Suggestion: "A table cell may span several columns or rows. This is specified by the table:number-columns-spanned and table:number-rows-spanned attributes. The rules defined in §11.2.6 of [HTML4] regarding the influence of table cells that span several rows or columns on later cells apply. This means that there shall not be <table:table-cell> elements in the row/column grid for positions that are covered by cells that spans several columns or rows. The <table:covered-table-cell> element exists to be able to specify cells for such positions." 8.1.20: Suggestion: "Applications that do not support header columns _may_ process header column descriptions the same way as non header column descriptions." 8.6.5: "17.614" has the wrong style applied. 8.7.3.1: The references have the wrong formatting applied. 8.10.1: Not sure, but rather than saying "The list contains an element for each change made to the table." saying "The list contains an element for each change made to _a_ table." sounds better to me, because a spreadsheet document may contain several tables. 10.4: "attribute" has the wrong formatting. 11.1: I'm not sure if removing the "relevant" may be misleading, as <office:database> does not define database elements, but only those that matter for a database document (which is not the same as a database). Suggestion: "A <office:database> element represents the content of a database front-end document." Suggestion 2: Move the description of this element into section 2, where <office:text> and so on are described. 11.3/11.4: Some element names are formatted incorrectly 12.1: Forms may be bound to an XForms model (which is then included in the <xforms:model> child element of <form:form>), but that XForms model is not an alternative to the <form:form> element itself. Therefore, it is not correct to say that form behavior is not defined for forms defined by <xforms:model>. I therefore suggest to remove the last two paragraphs, but to extend the bullet list by these items: * Unnested forms may be bound to an [XForms] data model. * Unnested forms may be submitted. 12.6: table 7: a -> an (several times) 12.7.1: Standard -> standard (not sure) 12.7.2: The new note is correct, but what is said here is not restricted to Boolean values. If the value-type attribute has the value "time", then only time-value is permitted at the list-value element, amd so on. Suggestion: Remove the note, or add a "For example". 15.27.2, third bullet item: The dot behind the first sentence has the wrong formatting. 15.27.3, third bullet item: The dot behind the first sentence has the wrong formatting. 15.28: A "for" seems to be missing in the first sentence. There is further an obsolete "objects" in the first paragraph. 16.12: This reads now as that the list item is part of a list label, but its vice versa. Suggestion: "The <style:list-level-label-alignment> element specifies the position and spacing of a list item and its label." Oliver, is that okay for you? Further, something with the following sentence seems to be wrong: "The value of the text:min-label-width attribute is treated as 0 making this value is also the alignment position for the list label." That is also the case for that one: "The value of these two list level attributes are considered only for paragraphs inside list items whose paragraph styles do not specify them list levels." Dataypes chapter: As reported by Peter, the heading information is missing for this chapter. 17.1: Standard -> standard? 17.7, fourth paragraph: A "not" in a "shall not" is not bold. 17.8: I think we should keep the following: "The effects of the next iterated child of the target element are started when the given time is elapsed since the effects for the previous child has been started. An iterate interval of zero seconds would have the same behavior as using a <anim:par> element." 17.15.1: "Similar" may be the wrong term, but I think we should keep some wording here that area and line charts have something in common. Suggestion: "Area charts equal line charts, except that" This comment actually applies to all chart types where a sentence containing "similar" has been removed. 17.73.5: Why is <db:component> mentioned? Appears to be unnecessary to me. 17.73.11: Why is <db:query> mentioned? Appears to be unnecessary to me. 17.106: dr3d:shade-mode has the wrong formatting 17.241: itemand -> item and 17.406: Some attribute names are not formatted correctly. 17.542: What is said here about linked images is not wrong, but the attribute may be applied to many other graphical objects as well. Suggestion: If the svg:height attribute specifies the width of a drawing shape that displays a picture, then the actual width of the picture may take precedence over the specified width. 17.618: The deleted text is implementation advice, but we have added it some time ago because where was some uncertainty whether or not a default cell style is applied to cells that are not explicitly defined by a table. 17.645: The described syntax is only a subset of the formula specification. When we introduced it as a "typical" syntax then this was okay, but without the "typical", the description of the syntax is not reasonable. Suggestion: Let's remove the syntax entirely (but keep was is said about the namespace prefix), and add a reference to the formula specification. 17.832: The first "typically" (the one that has been replaced with "by default") has to stay or has to be replaced with some other term. At least "by default" appears to be incorrect, because the tab stop is not by default located behind the label. That's only in most cases (or typically) the case. The 2nd typically should also remain: Only if the tab stop start behind the list label, the following text start at that tap stop. If the tab stop position is somewhere within the label, then the following text anyway starts behind the label. 17.837.9: title index -> index title (where is no index of titles, but each index may have a title) 17.856.1: text:ref-name has the wrong formatting 17.857: I'm slightly in favor of removing only the "typically" rather than just the full note. 17.894: (old one) paragraph -> paragraphs 17.897: an object is -> objects are(?) 18.14: "attribute" has wrong formatting 18.16: "it" has wrong formatting 18.18: "attribute" has wrong formatting 18.10: "chart:dimension" has wrong formatting 18.49: "it" has wrong formatting 18.57: I'm wondering whether we should keep "This completely preserves the object outline, which is in particular required for correct display of chart values in 3D charts." for the value "correct", and whether we should add "This preserves the visual appearance of extruded text." for "attractive". 18.75 (within the note): If it is the default (360deg) -> If _the attribute has_ the default _value_ (360deg) (?) 18.76 f -> if 18.388 "style:wrap-dynamic-threshold" has wrong formatting -- 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 -- 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]