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] Re: Timeline for ODF 1.1 Errata 01


Rob,

Thanks, it takes some schedule pressure to have the opportunity to have changes that may need to be rolled-up to AMD1 figured out in parallel.  It also helps if we don't need an approved ODF 1.1 Errata 02 before we identify and submit those to WG6. 

I will make a change-marked ODF 1.1 concurrent with preparing WDs for ODF 1.1 Errata 01.  I will verify the FPDAM1 changes at the same time and confirm that ODF 1.1 changes anticipated in FPDAM1 are caught for the ODF 1.1 Errata 01.  

 Most changes in  FPDAM1 will not reflect back on ODF 1.1.  They establish alignment and they work from the ODF 1.1 text and agreement with ODF 1.1 has been double-checked once already.  I don't think we will need to deal with a mechanical DIFF again.  The mechanical DIFF should only find ODF 1.1 differences from IS 26300 that somehow were overlooked in preparation of FPDAM1.   We can do that again after we have our own Errata done, but it should not reveal anything significant and can be done pretty late.

There are some changes made in the FPDAM1 where it was noticed that the difference from IS 26300 in ODF 1.1 contained obvious editorial defects.  In those cases, the FPDAM1 was produced on the assumption that those defects would be repaired.  The FPDAM1 also identifies where those are.  In some cases, ODF TC JIRA Issues have already been created.

I need to do an inventory in my records and in JIRA, but I believe there are only a small number of places where something was identified in WG6 that involved a need for an ODF 1.1 change and that was *not* anticipated in the AMD.  (For example, I recall two errata items in ODF 1.1 Errata 02 that did not make it into COR2 because of incompatibilities between the ODF 1.0 and IS 26300 texts.)

  - Dennis





Cases that will need to be turned into comments are editorial defects that were noticed in the WG6 work but not reflected in the FPDAM1.  I don't know off-hand whether those have been 

There are some other odd cases that will come up in the rolling-up ODF 1.0 Errata 02 to ODF 1.1 Errata 01 because of differences in COR1 and COR2 and what they change in 

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Tuesday, March 22, 2011 05:53
To: dennis.hamilton@acm.org
Cc: Michael Brauer ; ODF TC List ; Patrick Durusau 
Subject: [office] Re: Timeline for ODF 1.1 Errata 01

Hi Dennis,

I think there are two things we need to think about:

1) Changes we need to make to OASIS ODF 1.1, via Approved Errata, to make it incorporate any applicable Approved Errata we have already published for ODF 1.0.  This could be started any time and is not really dependent on the progress in JTC1, although of course it would be good to not lag that process too much.

2) Once we have done #1, are there any additional changes that we want to trigger in the ISO FPDAM text by submitting comments to that ballot.  (As a liaison we can't vote but we can submit comments).  Note that we don't need to have a 1.1 Approved Errata in hand before we can submit comments. 
It wouldn't hurt, of course.  But it is enough if we can submit a list of sections/line numbers in the FPDAM that we believe will need to be reconciled.  Then at some subsequent post-ballot WG6 meeting we can agree on the final list of changes.

There is another ballot, after the FPDAM, called the FDAM ballot.  I think it is 3-months long.  So there is an opportunity for us to ballot the OASIS Approved Errata at this point.

So I guess my point is that it is possible to do some parallel processing 
here with Errata.    For example, could the sequence go like this:

1) Determine the full text of the FPDAM (applying the changes described to the full text of ISO/IEC 26300).  We already have this, right?

2) Draft the OASIS ODF 1.1 Errata and produce a full ODF 1.1 text with the changes applied.  This could be done in either order.

3) Diff the draft of the corrected ODF 1.1 with the draft of the amended ISO/IEC 26300.  Are there any important discrepancies?  Anything that would break technical equivalence?  Fixes are cheap at this point, so I think we should take the opportunity to bring these documents as close together as possible.

4) For each discrepancy, evaluate how best to fix:

a) Fix in draft OASIS Errata
b) Fix in FPDAM

5) If any required a fix in the FPDAM text, submit a comment to that ballot before June 8th.

6) Public review (15-day) and ballot for OASIS Approved Errata.  I think this will end well before the FDAM ballot will.

Regards,

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 03/21/2011
11:04:44 PM:
> Timeline for ODF 1.1 Errata 01
> 
> Oh boy.  I've been coasting along thinking the end of the FPDAM1 
> ballot is months away and there's plenty of slack to have ODF 1.1 
> Errata 01 intercept that before the FDAM1 is produced.  Guess again,
Dennis.
> 
> I just did a setback roadmap.  It is ugly and I will go into immediate 
> crunch mode to not have it get worse.  Here's how it looks:
> 
> 2011-06-08: ODF 1.1 Alignment FPDAM1 ballot ends at JTC1 SC34
> 
> 2011-05-31: ODF 1.1 Alignment Comments from OASIS Liaison need to go 
> to SC34 (this seems like the latest possible).
>   Note: This is for anything that we do in Errata 01 that requires the 
> SC34 WG6 amendment to be adjusted for.  There are believed to be a few 
> items at this point.  This can be developed concurrently with the 
> procedural stages of the OASIS ODF 1.1 Errata 01, so there may be some 
> slack here.
> 
> 2011-05-15 ODF 1.1 Errata 01 Approval  This assumes that ODF 1.1 
> Errata 01 CSD01 goes through Public Review without any comments 
> requiring modifications and an additional Public Review.  Most of the 
> changes will be for alignment with ODF 1.0 Errata 02 and additional 
> ones noticed in the preparation of FPDAM1 should not create any 
> problems.
> 
> 2011-04-15 ODF 1.1 Errata 01 CSD01 Public Review Starts The setback 
> includes some slack for procedural delays as well as the 15-day public 
> review itself.
> 
> 2011-04-04 ODF 1.1 Errata 01 WD0y Balloted in the ODF TC for approval 
> as CSD01 and submission to Pubic Review
> 
> 2011-03-28 ODF 1.1 Errata 01 WD0x available for ODF TC review and
comment
> May have placeholder text in places to be completed by WD0y
> 
> 2011-03-24 ODF 1.1 Errata 01 WD01 available for ODF TC review and ODF 
> 1.1 Errata 01 on agenda for 03-28 call.
> There are some specific items I must confirm as part of setting this 
> up (especially the ability to derive an HTML version), but I will 
> attempt to improve on this date, no matter how sketchy the first draft
is.
>   Progress postings will be made as appropriate.
> 
>   I guess it is a good thing that my wife is visiting friends in 
> Brazil until the beginning of April.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Monday, March 07, 2011 08:43
> To: Rob Weir "robert_weir"; dennis.hamilton@acm.org
> Cc: Robin Cover
> Subject: WD-level starter document for
> 
> Rob/Dennis,
> 
> Attached is a nominal starter ("template") document for Open Document 
> Format for Office Applications (OpenDocument) Version
> 1.1 Errata 01
> 
> The Naming Directives are underspecified as to construction rules for 
> filename (pattern) and path/URIs, so the details can be
> negotiated.   I assigned something initially that seems to make
> sense but I need to think more deeply and examine the patterns for 
> Errata previously published.
> 
> The anomaly is that -errata- is itself identified as a stage (approval 
> stage) in the TC Process, coordinate with
> 
> [wd]
> csd
> csprd
> cs
> os
> errata <------- **
> 
> And yet
> 
> a) an Errata document progresses from
> wd -> csd -> csprd [Committee Specification Public Review Draft]
> 
> b) a spec can have numerous Errata documents, so we need identifiers 
> like 01, 02 to enumerate them
> 
> I came up with this provisionally:
> 
> OpenDocument-v1.1-errata-01-wd01.odt
> OpenDocument-v1.1-errata-01-wd02.odt
> OpenDocument-v1.1-errata-01-csd01.odt
> OpenDocument-v1.1-errata-01-csd01.odt [...]
> 
> which builds on the document identifier for the 1.1 spec
> 
> we could say "errata01" but IMO errata-01 looks better
> 
> OpenDocument-v1.1
> [OpenDocument-v1.1.odt]
> 
> Let me know if/when there's something further to be discussed.  Oh: 
> I bracketed "Conformance" because I didn't know if this is a diff or 
> in-place correction, etc.
> 
> - Robin
> 
> 
> 
> 
> 
> http://www.oasis-open.org/committees/process.php#standApprovProcess
> 
> 
> 
> --
> Robin Cover
> OASIS, Director of Information Services Editor, Cover Pages and XML 
> Daily Newslink
> Email: robin@oasis-open.org
> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> Cover Pages: http://xml.coverpages.org/
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> Tel: +1 972-296-1783
> 


---------------------------------------------------------------------
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]