OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

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

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

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

No Rob. Read the process document. The statement
above is inaccurate.

This group writes the charter.

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

Constrained to the latest Oasis standard. Today that's 1.1.
If the main TC gets 1.2 through processs then great
the IIC TC can be re-chartered appropriately.

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

Nope. Too many moving targets  and it won't deliver. 1.2 doesn't exist
as an Oasis standard.

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

Yes. Me. I think that's quite inappropriate and a time waster.

Obtaining feedback to a developing standard should be part of the main
TC's work.
So should testability. Not the job of the IIC TC.

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

Then don't make such proposals. Who would commit to test
something that isn't stable yet?

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

Yes. Bit like asking the implementers to validate their own software?
Hey, it passes!


Dave Pawson

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