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