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


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 



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