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
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" <>
> To:
> <>, <>
> 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: [mailto:]
> http://lists.oasis-open.org/archives/office/201001/msg00024.html
> Sent: Monday, January 04, 2010 10:04
> To:
> Subject: Re: [office] Proposal: Align IS 26300 to ODF 1.1 instead of 1.0
> maintenance
>
> "Dennis E. Hamilton" <> 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
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)
