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

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Rob,

Thanks for continuing to ponder on this along with Jamie Clark's useful
follow-up.  I think this is a very creative solution and we should pursue
it.

Patrick,

It sounds like the automated DIFF plus a clean version is the ticket.  It's
a little weird that both would be submitted as PDFs, but have to be made
using editable forms.  As long as we can pull that off, it should all work.

 - Dennis

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

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.

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 [;<).


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

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.

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

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



 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Thursday, January 07, 2010 06:58
http://lists.oasis-open.org/archives/office/201001/msg00075.html
To: robert_weir@us.ibm.com
Cc: dennis.hamilton@acm.org; office@lists.oasis-open.org
Subject: Re: [office] Proposal: Align IS 26300 to ODF 1.1 instead of 1.0
maintenance

Rob,

I will have to think about it a bit but this sounds like an interesting 
approach and one that the first steps could be done more quickly than 
alternative approaches.

I do think that ODF 1.1 "as is" should be expressed as an automated diff 
against ISO 26300 with a clean text to accompany it as amendment.

As I said, need to think about it but this might be a viable option.

Thanks!

Patrick

robert_weir@us.ibm.com wrote:
http://lists.oasis-open.org/archives/office/201001/msg00074.html
> HI Dennis, I just thought of a way to finesse the procedures a bit, so the

> concurrent errata are not an issue.
>
> It would go something like this:
>
> 1) Give JTC1 ODF 1.1 as-is.  Don't apply any errata at all.  It will 
> contain regressions compared to ODF 1.0
>
> 2) Although OASIS cannot vote in the amendment ballot, as an liaison we 
> can submit ballot comments. We would submit comments that essentially 
> reflect all outstanding errata.
>
> 3) As part of the ballot resolution process in SC34, the ISO text is 
> updated to include our submitted errata.  No additional OASIS public 
> review or approval needed at that point, since it is entirely on the ISO 
> side.
>
> 4) However, at the end of the JTC1 procedure we adopt the changes made 
> there as Approved Errata on ODF 1.1.
>
> This doesn't really eliminate any work.  We still need to do Approved 
> Errata in OASIS,   But what it does do is push that Approved Errata work 
> to the end of the schedule, rather than put it up front .  The end-to-end 
> time is the same, but it allows us to accelerate the submission of the 
> amendment, which effectively increases the interval between the 
> publication of ODF 1.1 and ODF 1.2.  It is still close, and I have note my

> concerns there, but it is a little better if we stage it as above.
>
> Note that with this approach the 2nd and 3rd defect reports (and even 
> future defect reports) are not a problem.  We just need to ensure that we 
> submit ballot comments that bring 1.1 into synch with any OASIS Approved 
> Errata that exist as of the end of the FPDAM ballot.  Although the 
> submission will contain regressions, the published amendment would not.
>
> What do you think?
>
> -Rob
>
>
>
> From:
> "Dennis E. Hamilton" <dennis.hamilton@acm.org>
http://lists.oasis-open.org/archives/office/201001/msg00025.html
> To:
> <robert_weir@us.ibm.com>, <office@lists.oasis-open.org>
http://lists.oasis-open.org/archives/office/201001/msg00024.html
> Date:
> 01/04/2010 04:26 PM
> Subject:
> RE: [office] Proposal: Align IS 26300 to ODF 1.1 instead of 1.0 
> maintenance
[ ... ]