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: ODF 1.2 Review of chapter 1 and 2


Hi Patrick,

I have reviewed chapter 1 and 2. Here are my comments:

1.1 Introduction: This chapter does not any longer describe the 
structure of the specification. Is that intended?

1.2 Notation: We have to add an “need not” when we integrate the 
conformance clauses (This is more a reminder for myself)

1.3 Namespaces: The usage of the prefixes in the specification is not 
explained. Rob made a proposal for this some time ago. It is at:
http://lists.oasis-open.org/archives/office/200806/msg00091.html

A reference to the schemas is missing (may become an appendix)

2.1 General: The 2nd and 3rd paragraph seem to fit better into section 2.4.

2.2 <office:document>: what about changing the heading to 
“<office:document> (Single OpenDocument XML Files)"

2.3 OpenDocument Packages: What about renaming the heading to “Package 
OpenDocument Files” to avoid the impression we are defining OpenDocument 
packages here.

In general, we seem not to have a consistent terminology when we talk 
about a file and when about a document, and how we call the streams 
within a zip file. The term “Subdocument” is used here but also 
“packagefile”, “sub file” and “file”.

Section 2.2.1 Pre-Defined vs. Custom Metadata of draft 6 is missing. 
This seems to be okay to me.

2.3 <office:meta>: Maybe we should state clearer that the child elements 
all are about the document itself.

2.4 <office:body>: Having at least some of the information of section 
2.3 of draft 6 may be helpful to understand the relation between the 
content of the <body> element and the document types. Also, the 2nd and 
3rd paragraph of 2.1 (draft 7) seem to fit better into this section.

2.4.1 <office:text>: Rather than saying “The <office:text> element 
represents a document “ we may want to say “The <office:text> element 
represents the content of a document”. The same applies to 
<text:spreadsheet> and so on.

2.4.6 Image: Suggestion: The <office:image> element represents the 
content of an image document. It consists of a single frame element that 
shall contain a single image element.

2.5 <office:settings> Information that this element contains application 
settings is missing.

2.5.3 <config:config-item-map-indexed>: Suggestiion: The 
<config:config-item-map-indexed> element is a container element for 
sequences of configuration items where the order of items matters.

2.9.2 <office:automatic-styles>: Some explanation of an automatic style 
is missing, although the one in draft 6 was not very detailed, too. 
Maybe the following does work:
An automatic style contains formatting properties that are considered to 
be properties of the object to which the style is assigned rather than 
dedicated style elements. There is no difference to common styles how 
the formatting properties are evaluated.
Note: Common and automatic styles behave only different in ODF editing 
implementations. While common styles are presented to the user as a 
named set of formatting properties, automatic styles are not presented 
to the user as such. Instead the formatting properties of an automatic 
styles are presented to the user as properties of the object to which 
the style is applied.

2.10 Page Styles and Layout: The explanations in section 2.8 (draft 6) 
seem to be missing. They actually better fit into the section which 
described the <style:master-page> element. My suggestion is therefore to 
add them there, and to entirely remove section 2.10.

18:90 config:name. The use of a namespace is only recommended for 
<config:config-item-set> elements, and only if they are a children of 
<office:settings>.

18:91 config:type: Should we list the possible types, even though this 
would be somehow a trivial list?

18.1155 text:global. The description of this attribute is incorrect. It 
is not the <office:document-*> elements that have part-of semantics, but 
the text sections contained in the document. From the text we had in 
draft 6, I think that the first half of the description actually better 
describes the semantics of the attribute than the 2nd half.

Best regards

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