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

[Patrick Durusau <patrick@durusau.net>]

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:
> 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>
> To:
> <robert_weir@us.ibm.com>, <office@lists.oasis-open.org>
> Date:
> 01/04/2010 04:26 PM
> Subject:
> RE: [office] Proposal: Align IS 26300 to ODF 1.1 instead of 1.0 
> maintenance
>
>
>
> Rob,
>
> I don't propose that we renege on defect processing but that we apply the
> ones we can to a 1.1 errata and bring them back to ISO as the IS 26300
> amendment for 1.1.  We could respond with dispositions but agree not to
> create more corrigenda until we have the 1.1-aligned IS 26300 to apply 
> them
> to.
>
> This might make some delays but it would have 1.1 be the common baseline
> (however we agree on equivalence) soonest. 
>
> I'm not sure which is the longest tent pole.  Our six month rule about
> errata (once we produced a 1.0 Errata 02) or the time that it takes to 
> move
> draft corrigenda through SC34 once approved as errata at OASIS.  I have
> assumed that the second would be a greater barrier to accomplishing 1.1
> alignment early.  While we're constrained on when we could have more 
> errata
> (after 1.0 Errata 02 or 1.1 Errata 01) to the respective OASIS standards, 
> it
> seemed like getting 1.1 into that stream was the most effective thing we
> could be doing, all else being equal.
>
>
> 1. QUESTIONS I DON'T HAVE ANSWERS FOR
>
>   1.1 Perhaps you know what the calendar setback would be for submitting
> 1.1-as-amendment before the September 2010 SC34 plenary and could it be 
> done
> earlier than that via SC34 WG6?
>
>   1.2 Also, I couldn't find anything in the JTC1 procedures that helped me
> understand what the checkpoints and lag times are for processing of a PAS
> submission.  Do you have some staging information that applies to that 
> case,
> once OASIS makes the submission?
>
>   1.3 With regard to the OASIS policies and procedures for submissions to
> another standards body, the question seems to be whether submission of an
> amendment for 1.1 alignment triggers that process, especially provision 1c
> on conduct of an OASIS Interop Demonstration.  I agree this might be a
> show-stopper.
>
> 2. MAKING THE AMENDMENT
>
>   2.1 I'm assuming that creating a version of 1.1 that has the errata
> applied is a production matter and not something that requires processing 
> of
> a new committee specification and taking the update through the OASIS
> Standard approval process.  Even if it were to require an OASIS ballot, 
> that
> is apparently a thirty-day deal if I am reading the TCScheduler 
> spreadsheet
> correctly.
>
>   2.2 I don't understand the exact process for taking such a 1.1 to SC34 
> as
> an amendment to IS 26300, and I'm not clear how a "diff" is handled, 
> unless
> we mean some sort of change-tracking version that has been "diff"ed 
> against
> IS 26300 (that is, 1.0 edition 2?) so we see deletions and insertions
> against 26300?
>
>   2.3 I agree that this might be constrained by the OASIS policy (see 1.3,
> above) and we should find out how that impacts the presumption of 
> simplicity
> for this approach.
>
> 3. WITH REGARD TO ODF 1.2 AT JTC1
>
>   3.1 My wildly-optimistic trial calendar for approval of ODF 1.2 suggests
> that we couldn't be making a PAS submission of an ODF 1.2 OASIS standard 
> to
> JTC1 before October, 2010, and I didn't even consider the
> three-independent-implementations requirement.  I don't understand the
> timeline for the submission within JTC1 so I don't feel comfortable making
> allowance for JTC1 procedural requirements and how they fit on a calendar 
> of
> SC34 plenary cycles, etc.  I do feel quite safe in assuming we wouldn't 
> see
> an ISO/IEC version before 2011. 
>
>   3.2 I don't know how to compare an amendment timeline with that for a 
> new
> PAS submission, but I speculate that a 1.1 amendment could be a year ahead
> of ODF 1.2 being approved and published at JTC1.  Maybe more, unless the 
> PAS
> submission of a new version of an existing standard is very streamlined.
> Any information you or others have on that would be very helpful.
>
>  - Dennis
>
>
>
> -----Original Message-----
> From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
> http://lists.oasis-open.org/archives/office/201001/msg00024.html
> Sent: Monday, January 04, 2010 10:04
> To: office@lists.oasis-open.org
> 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/04/2010 
> 11:47:17
> AM:
> http://lists.oasis-open.org/archives/office/201001/msg00021.html
>
>
>   
>> 1.2 It is important to have a stable baseline IS 26300 against which
>> an ODF 1.1 Addendum can be submitted.
>>
>>     
>
> The goal should be (IMHO) that the OASIS and ISO versions remain 
> "technically equivalent".  Since we do not make substantive changes in 
> OASIS Approved Errata, there is less room for trouble here, in practice. 
> Even if an amended ODF 1.0 was created in ISO and lacked one or more 
> approved corrigenda corresponding to OASIS Approved Errata, it should 
> still be "technically equivalent" to OASIS ODF 1.1, right?  I don't think 
> we get a good return on investment by pushing for more than "technically 
> equivalent".  In particular, there may be little incremental value in 
> striving for lexical equivalence of the texts.
>
>   
>> 1.3 The continuing processing of corrigenda against the unaligned IS
>> 26300 will add substantial delays to the achievement of a stable IS 
>> 26300 baseline against which an ODF 1.1 Addendum is to be applied.
>>
>>     
>
> Not necessarily.  The work required to submit ODF 1.1 is more around OASIS 
>
> requirements related to submitting OASIS standards to other organizations: 
>
>  http://www.oasis-open.org/committees/liaison_policy.php#submitwork  This 
> looks like it would require several months.  Producing Approved Errata, on 
>
> the other hand, simply requires a 15-day public review and a TC vote. 
>
>
>   
>> 2. PROPOSAL
>>
>> 2.1 The ODF TC ceases creation of further addenda against ODF 1.0 
>> and the IS 26300 counterpart, ODF 1.0 second edition.  Further 
>> processing of an ODF 1.0 Errata 02 will be suspended.
>>
>>     
>
> I don't think we could do this, since the ODF TC and OASIS have committed 
> to SC34 to process defect reports in a timely fashion.  And remember, any 
> JTC1 NB may submit a defect report at any time.  Even if WG6 agreed in 
> principle to hold off, that guarantees nothing, since it a prerogative of 
> any NB to submit a defect report.
>
> How about this:  Draw up a plan for what it would look like if we kept to 
> our defect report processing commitments as well as produced an amendment. 
>
>  Consider as well as the OASIS requirements for Interop Demonstrations, 
> etc., per the Liaison policy.  Map out what that schedule would look like. 
>
>  Compare it to the likely ODF 1.2 schedule, in OASIS and ISO.  See if any 
> of this makes sense.  If it doesn't, we can try to adjust, but I don't 
> think we want to automatically assume that we must renege on our defect 
> processing commitments.
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)