[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ODF 1.0 Maintenance + Synchronizationof OASIS:ISO/IEC
"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/16/2008 10:11:59 PM: > > NEW QUESTION > ------------ > > This must have been considered and I apologize for revisiting old analysis, > but I am curious if the current maintenance and incoming avalanche of > defect-report items justifies another look: > > 1. IS THERE ANY TECHNICAL OBSTACLE TO PROCESSING OpenDocument-v1.0ed2-cs1 AS > AN OASIS STANDARD? > It would be quite unusual to create a new OASIS standard for material that is older and inferior (in terms of accessibility, for example) to a more resent OASIS Standard, namely ODF 1.1. In particular I don't think I would support sending something out for review and balloting as an OASIS standard that had known accessibility defects. It sends the wrong message. Sure, we could wave our arms and say it was purely for "alignment" purposes, but opponents will immediately latch on to the (apparent) regression in accessibility and go to town with that. > 2. IF WE CAN DO IT, WHY IT MIGHT BE A POWERFUL IMPROVEMENT FOR MAINTENANCE > AND SC34 SYNCHRONIZATION: > > 2.1 The idea would be to process Second Edition CS1 without changes (no > applied errata) and go through the pain of an OASIS Standard ballot process > solely for the purpose of aligning with ISO/IEC now and for future > maintenance of PAS-submitted OASIS ODF Standards. > 2.2 The benefit would be to have a 2d edition of ODF 1.0 that is an OASIS > Standard and that is perfectly aligned with IS 26300:2006. > 2.3 We could now reconcile maintenance of ODF 1.0 with IS 26300 in a > direct way (first, using the errata we already have) and not go into > contortions where ODF 1.0 and ODF 1.0ed2 differ, and we could make errata on > the Second Edition that are directly responsive to such items that come up > with ODF comments and with defect reports from SC34. Comments and defect > submissions involving substantive changes would be deferred up-level to an > in-progress or subsequent version. > 2.4 All subsequent OASIS ODF Standards (ODF 1.1 and ODF 1.2) are > descendents of ODF 1.0ed2, so there is no discontinuity in the lineage of > OASIS Standard specifications. > > But, of course, it matters whether this is easily done under OASIS > procedures and is considered worthy. > I think we have a fishhook and the solution is to push it forwards, not backwards. Push defect fixes forward to ODF 1.2 and then ensure that ODF 1.2 is not changed in the ISO/IEC PAS process. That will prevent future divergence. Remember, ODF 1.0 is not used by any major vendor. Today IBM, Sun, Novell, even Microsoft are all on ODF 1.1 or ODF 1.2. Real-world use requires the accessibility fixes in ODF 1.1, at least among the real-world adopters of ODF, which tend to be public sector and are legally obligated to provide accessible solutions. So fixing things in ODF 1.0 is of little practical consequence. If ODF 1.0 were in wide use, I might agree with you. Now it would be more interesting to take all of the changes made in ODF 1.1 (and you can see them in the appendix) and apply those, as errata to ODF 1.0 (second edition) and then make this be the common version between OASIS and SC34. This would at least have the virtue of being a standard that is widely implemented. But it would be a significant task to do this. > 3. KEY ASSUMPTION > > I am operating under the assumption that ODF 1.0 versions will continue to > have overlapping lives and are generally intended to be upward compatible, > at least in the ODF 1.x series. > Once a standard, always a standard. The mere creation of ODF 1.x or 2.x does not eliminate ODF 1.0. There is no process for undoing a standard in OASIS, though there is a process in ISO/IEC, called "stabilization" for putting aside an obsolete standard. You essentially say that you will no longer do maintenance on it, neither corrigenda nor technical revision, and it is removed from the SC work program. > I presume that a PAS submission for ODF 1.2, say, would be viewed as a new > ISO/IEC Standard and not just a maintenance of IS 26300. I am guessing > about that. If it were to be IS 26300:2009, say, I think it would not be > presumed to obsolete 26300:2005 either way. > It is common for PAS (and Fast Track) standards to have future versions submitted as "technical revisions". I've certainly seen some submitted with language stating that it cancels and replaces previous versions. I don't know if we would do that, but I've certainly seen it happen. See Ecma C# Programming Language, for example. The second edition (ISO/IEC 23270:2006) carries the following note in the Forward: "This second edition cancels and replaces the first edition (ISO/IEC 23270:2003), which has been technically revised." > I am assuming that for the foreseeable future, ODF 1.x Standards do not > supplant any of their predecessors. This assumption is consistent with the > handling of other standards for (interchange) formats, since the formats may > be long-lived whether or not there is active development and interest in > extended versions. (I notice that XML 1.0 is about to go to edition 5, > although there is a complaint about substantive changes in that one.) > > > 4. SOAP BOX > > Finally, from my position of ignorance of the ins-and-outs of the PAS > process and the OASIS relationship with ISO/IEC JTC1, I would think that an > alignment of this kind would be viewed as a positive step in carrying out > PAS-submitter responsibilities for maintenance. > > It would certainly make our maintenance work more straightforward. Having a > common errata for ODF 1.0 and ODF 1.0ed2 would also make much more sense > (since almost all items will apply to both specifications), and the drive > for clarifications from SC34 and IS 26300:2006 adopters would be greatly > facilitate. > There are really two questions, and I think we should consider the first one carefully: 1) What maintenance work should we be doing? 2) And what will make that work easier? The question of what work we should be doing is a question for this TC and this TC alone. JTC1/SC34 does not set our maintenance priorities. We are not agents of SC34. We own the maintenance of ODF, the vendors, users and other parties represented on this TC. (And I should say that our TC roster includes 7 members of SC34, so they should feel free to speak up as well). In terms of my single vote on the TC, I will not be casting it to spend time and effort on making additional trivial editorial changes to a version of ODF that is not implemented by any member of the TC, nor dare I say by any member of SC34. Of course, we need to respond to defect reports submitted by SC34, and do so in a timely and courteous fashion. But we are not obligated to make any change to any particular version of ODF based purely on these defect reports. Responding to a defect report does not automatically mean creating another errata document. That is one possible response. Another possible response is to state that we will apply the fixes directly and only to ODF 1.2. That is at our discretion. You express concern for clarifications by ODF adopters. I share this concern. But I note that in processing the SC34 defect report, which as you've seen largely consists of trivial editorial comments, we have passed over dozens of publicly submitted comments on our comment list. We've taken the SC34 defect report out of turn and have since then delayed responding to early submitted public comments, many of which have raised more substantial questions than the SC34 defect report. So I am concerned that we are taking time to replace "A" with "An" and "the the" with "the" when more significant issues, some reported by you yourself, remain unacknowledged and unprocessed on the public comment list. -Rob > > > -----Original Message----- > From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] > Sent: Thursday, October 16, 2008 10:29 > To: office@lists.oasis-open.org > Subject: RE: [office] ODF_1.0_Errata_4h - Adjustments > > What if we pulled this item altogether from the draft errata document and > fixed it in ODF 1.2 only? What is the downside? Is the underlying issue > such that the continued presence of the defect in ODF 1.0 (and ISO/IEC > 26300) will present substantial practical difficulties to an implementor > or to other users of the standard? > > If not, I'd remove this item from the document. We can then approve what > we all agree on and give this item more consideration and possibly add it > to a future errata document. Maybe it would fit better on an ODF 1.1 > errata document? This is certainly within our rights as a TC. And even > ISO/IEC process allows a "Further consideration required" response to an > item in a defect report, so such a decision (provided we approve the > remaining items in a timely fashion) should be acceptable. > > -Rob > > > > > From: > "Dennis E. Hamilton" <dennis.hamilton@acm.org> > To: > <office@lists.oasis-open.org> > Cc: > <patrick@durusau.net>, <Michael.Brauer@Sun.COM> > Date: > 10/16/2008 12:34 PM > Subject: > RE: [office] ODF_1.0_Errata_4h - Adjustments > > > > Michael to answer your question: > > 1. To make the comparable change in the OASIS Standard ODF 1.0, we would > need to make changes in most of the section to have it become the same as > the section in IS 26300 (with its errata changes). That is because of the > title, the use of URI where IRI is wanted, and to provide correct editing > instructions. > > 2. We can do that. My recommendation for doing that is to have a separate > 17.5 erratum that only changes The OASIS Standard section, in addition tot > he one that only changes the IS 26300 section. To attempt to accomplish > all of that in one erratum where the changes required are quite different > seems simply unworkable to me. > > 3. I had hoped to avoid that work so we might avoid another discussion > about substantive changes *and* to deal with the SC34 defect report. It > is my understanding that the SC34 defect report is not about the OASIS > Standard ODF 1.0. It is about IS 26300:2006. What we are stumbling over > is the fact that this is a place where IS 26300 and OASIS ODF 1.0 are > different and can't be resolved against the defect report using identical > corrections. > > That is my thinking. > > 4. I see no technical problem with making the change to align OASIS ODF > 1.0 with IS 26300:2006 (ODF 1.0ed2-cs1 for us), but I don't believe it is > appropriate to attempt it by adjusting just the one paragraph in the same > erratum as the change to IS 26300. > > 5. QUESTION: Is it appropriate and desired that we retrofit the IS 26300 > modifications (after application of errata) to the OASIS Standard ODF 1.0 > specification via the errata? > > - Dennis > > PS: I don't know the answer to the question. I'm concerned that it is a > substantial matter. > > -----Original Message----- > From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] > http://lists.oasis-open.org/archives/office/200810/msg00078.html > Sent: Thursday, October 16, 2008 03:39 > To: dennis.hamilton@acm.org > Cc: office@lists.oasis-open.org; patrick@durusau.net > Subject: Re: [office] ODF_1.0_Errata_4h - Adjustments > > Dennis, > > On 10/16/08 08:22, Dennis E. Hamilton wrote: > http://lists.oasis-open.org/archives/office/200810/msg00077.html > [ ... ] > > > RECOMMENDATION: > > > > 3. I changed the paragraph to be replaced to have the IS 26300 text, not > the ODF 1.0 text. > > The errata is an errata for ODF 1.0. I therefor think it does not work > to have only the ISO 26300 text here, because this simply does not exist > in the ODF 1.0 document for which we provide the errata. > > I have no objections to providing the ISO 26300 in addition to the ODF > 1.0 text. > > > > > 4. I indicated that the change is not to be made only to IS 26300 and > not to OASIS ODF 1.0. > > > > This becomes an accurate change for IS 26300:2006. The change is not > needed for OASIS ODF 1.0. > > But we are creating an errata for ODF 1.0, not ISO 26300. The only > reference to RFC2396 is the one in section 17.5. We do not get > inconsistent if we replace that with a reference RFC3986 and RFC3987. We > did that for ODF 1.0 2nd edition already. > > Why don't we just update the ODF 1.0 specification by the errata to what > we have in ODF 1.0 2nd edition/ISO 26300 anyway, of cause with applying > the additional errata we are discussing here? The only thing that was > missing is an additional reference to RFC3987. > > [ ... ] > > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]