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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: RE: [office] Proposal: Align IS 26300 to ODF 1.1 instead of 1.0 maintenance


"Dennis E. Hamilton" <dennis.hamilton@acm.org> 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


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