Re: [office] review of ODF 1.2 draft spec

[Patrick Durusau <patrick@durusau.net>]

Doug,

Thanks!

I won't have time to respond to it today but the questions are greatly 
appreciated. Having "new" eyes look at it will help find under specified 
areas and other issues.

Hope you are having a great day!

Patrick

Doug Mahugh wrote:
>
> 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 <http://blogs.msdn.com/dmahugh>
>

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