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

["Dave Pawson" <dave.pawson@gmail.com>]

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.



 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,

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!

regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk