Re: [oiic-formation-discuss] Which is definitive odf?

[robert_weir@us.ibm.com]

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 06/19/2008 05:59:20 PM:

> 2008/6/19  <robert_weir@us.ibm.com>:
> 
> >
> > I don't think ISO status has any relationship to interoperability
or
> > conformance.  In fact, the most-commonly used ODF version
today is ODF 1.1,
> > which is not an ISO standard.
> >
> > In the end, I think choosing the ODF version is a "privilege
of membership"
> > for those who actually join the proposed TC.  I don't think
we can expect
> > for example, that a TC formed mainly of ODF 1.1-supporting implementors
and
> > users will want to target ODF 1.2 first.  Similarly, a TC
with mainly ODF
> > 1.2 implementors/users represented would not want to target ODF
1.1.  We
> > really need to see the composition of the proposed TC to answer
this
> > question.  The work of the TC must be relevant to its members.
 Otherwise,
> > why would they invest the time to serve on it?
> 
> 
> In which case I'd prefer this group to define a version of ODF to
be
> used.  Leaving it to the TC risks too much politics.
> 
> If 1.1 is the current stable Oasis release that would make most sense.
> Unless 1.2 is nearing release by the time the TC starts work.
> 


I don't think we want this in the scope statement.
 If the scope of the TC is to work with ODF 1.1, then we would need
a new TC, or to recharter in order to ever work with ODF 1.2.  That
would be silly.

We probably don't want to put it in the goals section
that our goal is to improve interop with ODF 1.1.  Our goal statement
should encompass everything we want to do.

But I could certainly seeing our list of deliverables
call out an ODF 1.1-specific conformance and interop requirements docs
and test suites.  We could also list ODF 1.2-specific ones as well
and make the ordering clear when we give the estimated dates.

Stated differently, does anyone doubt that the same
OIIC TC could work on ODF 1.1 for some things (like test suites) while
also working on other things for ODF 1.2 (like providing pre-approval feedback
to the TC)?  I think that would be the optimal mode of operation,
if we had enough interested parties.  We could even divide up these
tasks into different subcommittees.  We obviously don't want to over-commit,
but I also don't want to prematurely force us into a single-threaded work
plan.

You say, "Leaving it to the TC risks too much
politics."  I say "Leaving it to the TC means the people
who will actually do the work will determine the order of the work".
 Is that such a bad thing?  

-Rob