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 ODF 1.2 draft spec


Dear TC members,

 

Several of my Microsoft colleagues are reviewing the ODF 1.2 draft spec, and I've started receiving their feedback.  Knowing that the TC is trying to get things wrapped up by November 17, we're planning to finish our review in the next week or so.

 

The first batch of feedback is below.  We haven't written specific proposals for anything yet, because I want to make sure that we've not misunderstood the context or background for these items.

 

FYI, Eric Patterson has recently become a TC member and he'll be helping me organize our feedback and proposals.  He is on the Excel team and is very familiar with the details of Excel's ODF implementation that will ship in Office 2007 SP2 in the first half of 2009.

 

All feedback welcome.

 

Regards,

Doug

 

 

data-pilot-groups

 

The ODF schema indicates that the following <table:date-pilot-groups> attributes are required: table:date-start, table:date-end, table:start, table:end, table:step, table:grouped-by.  While the requirement makes sense for some types of <table:date-pilot-fields grouping>, manually arranged (by name) fields should not have this requirement.  Can these attributes be designated as optional or clarified in some way?

 

 

explanation of style hierarchy - Section 2.9 Styles or Section 15 Styles

 

The spec doesn't seem to explain the relationship between styles and the order in which they are to be applied.  There are a few mentions of this process in the description of some properties that rely on the parent style for addition information (e.g. relative font size).  It would be useful to include a section describing the order in which styles (parent styles, styles inherited from containing elements, etc) are applied to a text:span or a text:p (preferably with an example as well).  It would also be helpful to outline exceptions to the rules (e.g. should text in a textbox inherit properties from styles outside the textbox?)

 

 

tracked changes - Section 4.6

 

It would be useful to include detail as to how to reconstruct documents with tracked changes when the changes are rejected.  For example, how should the deletion of list items be tracked and re-inserted if the change is rejected?  It would also be useful to add support for tracking changes in headings, tables, lists, fields, etc. in text documents.  And, to update the format change tracking to retain the original formatting applied.

 

 

standardized format for connection resource string - Section 6.6.2.1

 

It would be useful to define a standardized format for the connection resource to a source database.  This will allow all ODF processors to connect to the same databases.

 

 

style:num-format - Section 18.789

 

The list of numbering formats is restricted to three formats.  What should the behavior be for applications which support a superset of these formats?  Is there a default specified for the attribute?

 

 

additional support for text:section - Section 4.5

 

It would be useful to allow text:section to have the following properties: top and bottom margin, borders, line number, and also headers/footers.

 

 

Section 9.7

 

In this draft, only <draw:frame> objects can be set to be presentation shapes.  It would be useful to allow <draw:custom-shape> (section 9.6) and other objects to also be presentation shapes.  In addition, a change would need to be made to section 18.594 so that the presentation:class attribute could be attributed to <draw:custom-shape>.

 

 

Section 18.670 – smil:repeatCount

 

The editor’s note reflects that ODF only allows nonNegativeIntegers, while SMiL allows floating point.  PowerPoint supports repeating animations a non-integral number of times, so it would improve interoperability if floating-point values were allowed.

 

 

Section 18.594

 

To allow for better interoperability, it would be useful to have more through definitions of the presentation:class enums, and of the behaviors that OpenOffice attaches to various classes.

 

Doug Mahugh | Senior Program Manager | Office Interoperability | 425-707-1182 | blogs.msdn.com/dmahugh

 



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