"Dennis E. Hamilton" <> wrote on 01/07/2010
01:38:46 PM:
.
.
.
>
> THREE CONCERNS
>
> 1. For immediate attention: The Corrigendum that corresponds to our ODF
1.0
> Errata 01 is out there somewhere as approved IS 26300 updates and there
is
> potentially going to be what version control systems call an update
> collision. We will have to get the timing right on that for the
> "regression" to work. (I think it is a matter of whether the copy of IS
> 26300 that goes into the diff has the corrigenda applied or not.)
>
That DCOR is still under ballot, but will presumably be approved soon.
The nice thing about my approach is we can totally ignore errata/DCORs for
now. Just go ahead with the amendment. Diff ODF 1.0 (second edition) and
ODF 1.1 and toss the results over to SC34. Let them start their 9-month
slog through the amendment process. Remember, approving an amendment in
JTC1 takes just as long as approving a standard. It is the same stages
and process.
But we will have an end-loaded requirement to reconcile the amendment with
all corrigenda. This is stated in JTC1 Directives 15.5.3: "Each amendment
shall list the status of all amendments and technical corrigenda to the
current edition of the standard." But I don't see why this reconciliation
cannot be deferred until a BRM, especially if we are dealing with a
relatively small number of errata, none of which are substantive changes
and none of which apply to OASIS ODF 1.1.
We would also have an end-game requirement to process an ODF 1.1 Approved
Errata corresponding to that additional change set.
> 2. For the end-game: We will have to be *extremely* careful and
meticulous
> in ensuring that we have (technical) alignment of IS 26300 and ODF 1.1
at
> the end of this dance, with no unintended regression in ODF 1.2 on its
> achievement of OASIS Standard.
>
I think we can be absolutely sure that ODF 1.2 will be already submitted
to JTC1 before the 1.1 amendment and BRM concludes. So we'll need to
carry over any additional reconciliation items into the ODF 1.2 BRM.
So it looks like this:
1. OASIS submits delta between ODF 1.1 and ODF 1.0 (second edition.
Actually, the ODF TC doesn't need to review or approve anything here, at
least not formally.
2. JTC1 processes this as an amendment
3. OASIS created ODF 1.0 Approved Errata 02 (responding to both remaining
defect reports)
4. JTC1 processes these as DCOR 2 (relatively fast ballot, so done before
amendment ballot finishes)
5. OASIS creates ODF 1.1 Approved Errata corresponding to both DCOR and
submits them as ballot comments on the amendment. (This could be done in
either order).
The nice thing about this is we don't impact the ODF 1.2 schedule, since
the OASIS work is back loaded. Sure, JTC1 gets a specification that is
current for only a few months, but as Patrick suggests, why bother arguing
with them?
> 3. If the OASIS Board of Directors doesn't grant us an exception (and
I'd be
> surprised if they didn't) or maybe for planning either way (to shed
critical
> path), we could go ahead and look at having the requisite
Interoperability
> Demonstration early this year, even if it ends up being only ceremonial.
It
> should be easily accomplished (though I haven't read the guidelines) in
> terms of available ODF 1.1-supporting independent implementations. There
> does not seem to be an appropriate ODF Plugfest event early enough for
> piggy-backing this (since the FOSDEM event limits participation to
> open-source implementations), but perhaps dates in Brussels contiguous
with
> the FOSDEM 2010 conference period might work? For better lead time, the
> tentative Plugfest in Spain might serve better:
> <http://plugfest.opendocsociety.org/doku.php>. Or a highly-symbolic
> concurrent event in Stockholm perhaps [;<).
>
I think we would need a waiver on the Interop Demonstration, since
arranging that will significantly delay submission. In fact, my support
of the amendment submission would be predicated on two things:
1) It does not delay the completion of ODF 1.2
2) It does not look extremely silly, e.g., ODF 1.1 amendment comes out
after ODF 1.2 is already approved.
>
> OBSERVATIONS
>
> By rearranging the dependencies I see the plain 1.1 submission
accomplishing
> the following:
>
> 3. It allows us to continue to implement our commitment on feedback and
> resolution of defect reports from WG4 (or otherwise via SC34).
>
Yes.
> 4. It allows us to demonstrate our commitment to alignment between OASIS
and
> ISO/IEC versions ASAP with the earliest-possible submission of 1.1 to
JTC1.
>
Yes, though this same commitment would be also demonstrated by completing
and submitting ODF 1.2. Remember, everything that is in ODF 1.1 is also
in ODF 1.2. I don't think we've heard anyone in JTC1 express a technical
preference for one over the other. It is mainly a concern that there is
not an ISO standard corresponding to the latest OASIS standard. To the
extent ODF 1.1 is the latest OASIS standard, we go down one path. But
once ODF 1.2 is an OASIS standard, it will look silly to be submitting ODF
1.1 to ISO.
> 5. It unlocks some dependencies for parallel effort while the critical
path
> (the JTC1 amendment process) and its end date are brought as early as we
can
> practically make it. It may even allow our six-month critical paths on
> successive OASIS ODF 1.1 Errata to be completely absorbed under the
ISO/IEC
> critical path and eligibility periods for submission of comments against
the
> amendment (and back to 1.1).
>
Remember,
> 6. We should be able to get this onto the WG4 agenda for Stockholm and
> earlier to confirm alignment between OASIS and SC34 on this approach
> (although we will probably already be in motion) to the degree that will
> also reduce procedural delays (and establish good will) at SC34 (WG4).
>
Two ways of doing it: Submit an NP (new work item) to JTC1 and let them
do a ballot on that. Or request a subdivision at the SC Plenary. The
time is around the same either way, since the ballot is 3-months and the
plenary is three months away.
-Rob
