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] Discussion: Advancing the Parts of ODF 1.2 to CommitteeSpecification


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 03/09/2009 
01:06:52 PM:
> 
> Two weeks ago we had a brief discussion about interdependencies of 
> the three parts of ODF 1.2 and how we should progress the parts, 
> whether in parallel, in synchronization, etc.
> 
> I think about this too, and I would like us to discuss the following
> progression:
> 
> 1. Part 1 and Part 3 Progress Together. 
> 
>    1.1 The first public review of Committee Draft for Part 1: 
> Introduction and OpenDocument Schema should be accompanied by a 
> public review of Part 3: Packages.  I found 60 mentions of packages 
> in Part 1 and it looks like these should be reconciled together.  In
> addition, I don't think the scrutiny expected in a public review is 
> possible unless both parts are available to coordinate.
> 

I think this is an argument for ensuring that we understand the 
implications of the 60 package references in Part I before we approve Part 
I as a Committee Specification (the vote after the public review).  But I 
don't see it as a constraint on when do we do a public review.

And remember, we can slice and dice it in other ways as well.  For 
example, send Part I out for public review, and half-way through that 
review (30 days into it) send out Part III.  Or, note that the 60-day 
public review is a minimum.  We could decide to have a 90 day review of 
Part I and send Part III out 60-days later, so it overlaps Part I's review 
for 30 days.

So I agree that some level of coordination is desirable.  However, the 
vast majority of Part I has nothing to do with packaging, so I would not 
want to hold it up if otherwise complete.

>    1.2 Whether subsequent public reviews involve one or the other, 
> or both, will depend on what comments have been and what has changed.
> 

Subsequent reviews are required based on whether we make substantive 
changes.  It doesn't depend on the comments received.  The public comment 
period is not a vote.  We are free to make or not make changes.


> 2. Part 2 Progresses Independently
> 
>    2.1 It is striking, to me, that OpenFormula has been written in a
> way where it is independent of (any version of) ODF, and it can 
> simply be introduced into ODF 1.2 Part 1 by reference in a single 
> place.  (There might need to be a bit more profiling than just 
> identifying OpenFormula as a preferred selection for a table:formula
> namespace, but it is mostly that simple.)
> 

That was the idea.


>    2.2 There are some dependencies on ODF stated in the OpenFormula 
> specification, but I suspect those can be done in a way that does 
> not limit OpenFormula to a specific version.
> 

Do you recall what some of these dependencies were?  I'd rather have 
OpenFormula be independent of ODF, or even independent of XML if this is 
possible. 


>    2.3 Because OpenFormula is so substantial and so different, I 
> think we should prepare to move it to Committee Draft and Committee 
> Specification independently.  At that time, we can consider whether 
> there is merit in advancing to OASIS Standard separately as well.
> 

These are three different decisions.  My general feeling is to move things 
to public review as soon as they are ready for it.  It is the sole 
efficiency in this process that we can have a public review on one part 
while we simultaneous edit, or respond to comments, on another part.  We 
should seek out ways to parallelize this effort as much as we can.


>    2.4 Assuming that OpenFormula is available early enough, I can 
> see it used with ODF 1.1 processors as part of preparation for 
> migration to ODF 1.2 over time.  The way OpenFormula is specified, 
> this transition step for ODF 1.1 (and for ODF 1.2 implementations 
> that don't yet employ OpenFormula) is very appealing.
> 

Remember, OpenFormula was specified based on current spreadsheet practice. 
 It is not merely a mental exercise.  From what I've seen most spreadsheet 
implementations are already very close to implementing the semantics of 
OpenFormula.

>    2.4 Test Cases.  I hate to see the test cases lost.  They are 
> important in reviews and in preparation for implementation.  I think
> we should discuss having OIC provide custody for the test cases on 
> their SVN repository so they can be maintained and kept current for 
> public use.  Alternatively, the ODF TC could ask for an SVN 
> repository and also add support for the test cases to the ODF Wiki. 
> They key concern is assuring that the test cases are available and 
> usable along with the committee drafts, etc. I suggest OIC because 
> it is already learning how to operate with this kind of material.
> 

1) We could leave them in the specification, mark them as "examples" and 
state that examples are Informative only. 

2) We could remove them from the specification and make them available to 
the public by the ODF TC.  In fact we could even create a document 
"OpenFormula Test Cases" and publish that as a Committee Specification if 
we wish.

3) If those who have contributed to the test cases agree, these test cases 
could be contributed to the OIC TC via that TC's comment list.  Although 
the OIC and ODF TC's have some overlapping members, and both have RF with 
Limited Terms IPR modes, we can't simply toss material over the fence from 
one TC to another.  We would need a formal contribution.  We should check 
with Mary on whether the TC as a whole can vote to make that contribution, 
or whether we need this to be done by the original contributors.

-Rob


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