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: Re: [office] Review of CD01 Rev 4


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)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]