[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 <email@example.com>: > > > "Dave Pawson" <firstname.lastname@example.org> 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