OASIS Open Document Format for Office Applications (OpenDocument) TC

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 

Hi,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> ...
> 
> 16.12: This reads now as that the list item is part of a list label, but
> its vice versa. Suggestion:
> "The 

Hi Michael,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi Patrick, all,
> 

[...]

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

+1

> 
> What about adding a note after the first paragraph:
> 
> "Note: This table model basically equals that of HTML and XSL."

+1

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

I would say:

"Table rows and cells may be empty. Depending on the representation of
empty content, identical tables may be represented with a different
number of rows and cells.

> 
> Note: .... To save space, implementations may ...

I'll bet this would get an comment on the public list ;-), asking to
define 'space'. How about "To save storage resources, ..."?

[...]

That's all for now. Haven't been through section 17 and 18 yet, which is
more than half of the document.

Best regards,
Peter


-- 
Peter Junge
Open Source Strategy Director

Beijing Redflag Chinese 2000 Software Co., Ltd.
Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
Beijing Economic-Technological Development Area
100176 Beijing - P.R.China

北京红旗中文贰仟软件技术有限公司
地址：北京经济技术开发区（亦庄）西环南路18号汇龙森A座二层
邮编：100176

电话/Tel: +86-10-51570010 ext.6183
邮箱/e-mail： peterjunge@RedOffice.com
http://www.RedOffice.com

Peter,

Peter Junge wrote:
> Hi Michael,
>
> Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>   
>> Hi Patrick, all,
>>
>>     
>
> [...]
>
>   
>> 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.
>>     
>
> +1
>
>   
>> What about adding a note after the first paragraph:
>>
>> "Note: This table model basically equals that of HTML and XSL."
>>     
>
> +1
>
>   
The problem arises in what would we mean by "basically equals"?

Notes don't contain normative text so the "basically equals" isn't as 
bad there as in normative text but I would prefer to say in what way we 
are or are not the same. For example, what parts of the table model of 
XSL do we follow? (see http://www.w3schools.com/xslfo/xslfo_tables.asp 
for example) Or of HTML?

Or we could say, the ODF model is the same except .... (list components 
that are different/missing).

My objection is to implying difference and then not saying what that 
difference is. If we know what the difference is, then let's say that, 
even in a note. If we don't, then we really should find out.
>> 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.
>>     
>
> I would say:
>
> "Table rows and cells may be empty. Depending on the representation of
> empty content, identical tables may be represented with a different
> number of rows and cells.
>
>   
Err, don't you mean that the application of styles to "a" table may 
result in different presentations? (not just different number of rows 
and columns)
>> Note: .... To save space, implementations may ...
>>     
>
> I'll bet this would get an comment on the public list ;-), asking to
> define 'space'. How about "To save storage resources, ..."?
>
>   
Yes, I suspect it would and justly so. How about simply taking out 
advice on implementation issues? There are any number of things that 
could be suggested that aren't so why insert this one?
> [...]
>
> That's all for now. Haven't been through section 17 and 18 yet, which is
> more than half of the document.
>
>   
Oh, that's the best part! ;-)

Deeply appreciate the comments!

Hope you are having a great day!

Patrick
> Best regards,
> Peter
>
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)