OASIS Open Document Format for Office Applications (OpenDocument) TC

So we've received a good number of comments on the CD06 draft. I've moved all public comment list comments over into JIRA, where you can see them classified as "affects" CD06, issues 3558-3652 inclusive. I assume we want to fix all valid errors that were reported. It seems to be that there are two ways to fix the errors: 1) Revise the CD, vote to approve it as CD07, vote to send out for 15-day public review, then approve as Committee Specification, then (under the new OASIS rules) send for a further 60-day OASIS Candidate Standard public review, then a ballot as an OASIS Standard. This puts us out around 4 months, to April. And this assumes that we do not receive, or opt not to act on, additional reports of typographical errors during the 15-day follow up review. 2) Do not revise the CD, but immediately vote to approve as Committee Specification and ballot as an OASIS Standard (under the old rules), giving us an OASIS Standard in February. We could then make any non-substantive changes in the form of Errata for ODF 1.2, which would require only a 15-day public review. So unless we think that there are serious technical changes needed, the fastest way to a corrected text is to go forward with an immediate Committee Specification vote now, followed by Errata (which could be prepared in parallel with the OASIS Standard ballot) with an Approved Errata ballot immediately following approval of the OASIS Standard. However, if we think that there are "must-fix" technical issues that arose in the public review, then the current Approved Errata rules would not allow substantive changes, i..e, changes that would make a conforming implementation non-conforming. You may have heard that the OASIS Board of Directors is debating whether or not to relax that "substantive change" restriction in Errata, but no final decision has been made, so we might not want to bet on it quite yet. But there is a likelihood that we'll eventually be able to make technical corrections, but not technical additions, in Errata. In any case, I'd ask members to review the new JIRA issues that have been entered during the public review. These contain all comments received. If there is any issue that you think is a "must fix"and is something that may not be fixed in Approved Errata (under current rules) please be prepared to bring this up on Monday's calls. It would also help if you sent a note to the list listing such issues. Regards, -Rob ----- Forwarded by Robert Weir/Cambridge/IBM on 01/01/2011 12:21 PM ----- From: Mary McRae <mary.mcrae@oasis-open.org> To: Robin Cover <robin@oasis-open.org>, OpenDocument Mailing List <office@lists.oasis-open.org> Date: 12/30/2010 10:07 AM Subject: [office] ODF v1.2 submission for OS ballot As today is my last official working day at OASIS, I'm writing this so everyone is clear as to the possible timelines going forward. Robin has been appointed interim TC Administrator and will be working closely with you should you decide to move forward in January. The public review ends 1 January. Comments were received, so the TC cannot request a special majority ballot to approve as a Committee Specification until 8 January. The ballot needs to START on 8 January so any advance notification you can give Robin would be greatly appreciated. You will also want to request a simultaneous ballot to submit the CS for OASIS Standard ballot (contingent on the CS ballot passing). Both of these ballots must be run by the TC Administrator and require special majority to approve. The ballots will close at the usual 11:45pm ET on the 15th. In the interim, the Chairs will want to assume approval and prepare the formal OS submission request so that Robin receives it on or before 11:59pmET on the 15th. Should all those conditions be met, the ballot will proceed per the old rules and the formal ballot will run 16-28 February. Should the TC decide to make further changes to the specification, another public review cycle will be required. At that point the TC will no longer be able to take advantage of the transition period as noted in the TC Process and will then need to follow the Candidate OASIS Standard procedure. All the best going forward, Mary Mary P McRae Director, Standards Development Technical Committee Administrator Member Section Administrator OASIS: Advancing open standards for the information society email: mary.mcrae@oasis-open.org phone: 1.603.232.9090 Standards are like parachutes: they work best when they're open. Important Links for all TC Members: TC Handbook: http://docs.oasis-open.org/TChandbook/ TC Process: http://www.oasis-open.org/committees/process-2010-07-28.php TC Admin Requests: http://docs.oasis-open.org/templates/TCAdminRequests.html --------------------------------------------------------------------- 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

Hi, Some of the comments on the JIRA issues state "The comment is not in scope of the PRD02 public review." It is not quite clear to me what "in the scope of PRD02 public review" means. There are clearly some parts of the document that were not since the last review but whose meaning or interpretation has changed due to changes elsewhere. For example OFFICE-3583, the term in question there (escape angle) was replaced elsewhere with a different term (leaving angle), so while there was no change in this specific place the changes that were made elsewhere have made this (in my mind) clearly an item in scope for this review. Andreas -- Andreas J. Guelzow <andreas.guelzow@concordia.ab.ca> Concordia University College of Alberta

"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/02/2011 01:18:07 PM: > > Some of the comments on the JIRA issues state > "The comment is not in scope of the PRD02 public review." > > It is not quite clear to me what "in the scope of PRD02 public review" > means. There are clearly some parts of the document that were not since > the last review but whose meaning or interpretation has changed due to > changes elsewhere. > > For example OFFICE-3583, the term in question there (escape angle) was > replaced elsewhere with a different term (leaving angle), so while there > was no change in this specific place the changes that were made > elsewhere have made this (in my mind) clearly an item in scope for this > review. > The OASIS rule is: "Changes made to a committee draft after a review must be clearly identified in any subsequent review, and the subsequent review shall be limited in scope to changes made in the previous review." So the scope is limited to "changes made in the previous review". However, I'd tend to read that broadly, to include explicit text changes as well as those unchanged parts of the text whose interpretation has changed based on the explicit text changes. Regards, -Rob

On 2011-01-02, at 15:43, "robert_weir@us.ibm.com" <robert_weir@us.ibm.com > wrote: > "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on > 01/02/2011 > 01:18:07 PM: > >> >> Some of the comments on the JIRA issues state >> "The comment is not in scope of the PRD02 public review." >> >> It is not quite clear to me what "in the scope of PRD02 public >> review" >> means. There are clearly some parts of the document that were not >> since >> the last review but whose meaning or interpretation has changed due >> to >> changes elsewhere. >> >> For example OFFICE-3583, the term in question there (escape angle) >> was >> replaced elsewhere with a different term (leaving angle), so while >> there >> was no change in this specific place the changes that were made >> elsewhere have made this (in my mind) clearly an item in scope for >> this >> review. >> > > The OASIS rule is: "Changes made to a committee draft after a > review must > be clearly identified in any subsequent review, and the subsequent > review > shall be limited in scope to changes made in the previous review." > > So the scope is limited to "changes made in the previous review". > > However, I'd tend to read that broadly, to include explicit text > changes > as well as those unchanged parts of the text whose interpretation has > changed based on the explicit text changes. I would agree with that reading, and so claim that OFFICE-3583 is in fact in scope. Andreas

robert_weir@us.ibm.com wrote: > "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/02/2011 > 01:18:07 PM: > >> Some of the comments on the JIRA issues state >> "The comment is not in scope of the PRD02 public review." >> >> It is not quite clear to me what "in the scope of PRD02 public review" >> means. There are clearly some parts of the document that were not since >> the last review but whose meaning or interpretation has changed due to >> changes elsewhere. >> >> For example OFFICE-3583, the term in question there (escape angle) was >> replaced elsewhere with a different term (leaving angle), so while there >> was no change in this specific place the changes that were made >> elsewhere have made this (in my mind) clearly an item in scope for this >> review. >> > > The OASIS rule is: "Changes made to a committee draft after a review must > be clearly identified in any subsequent review, and the subsequent review > shall be limited in scope to changes made in the previous review." > > So the scope is limited to "changes made in the previous review". > > However, I'd tend to read that broadly, to include explicit text changes > as well as those unchanged parts of the text whose interpretation has > changed based on the explicit text changes. I agree to this, and when classifying the comments, I've tried to follow this approach. But for OFFICE-3583, this in my opinion does not apply. The interpretation of the two sentences that do contain the term "escape angle" did not change because we replaced the term "escape angle" with "leaving angle" in a third sentence. Anyway, what's more important here is that the question whether or not an issue is marked as "in scope" doesn't has any impact on whether and when we resolve it. The purposes of the flag is only to enable counting and tracking of issues that are in scope. That's required, because a) if there are issues that are in scope we need to wait a week before we could request a CS ballot (but the actual number does not count), and b) we need to acknowledge only issues that are in scope. Of course, we may also care about other comments, but even in this case, I strongly recommend to track things accordance with the OASIS rules. Best regards, and a happy new year. Michael > > Regards, > > -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 > -- Michael Brauer Oracle Office Development Phone: +49 40 23646 500 Oracle Office GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven