[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ODF 1.0 Maintenance + Synchronizationof OASIS:ISO/IEC
Robert, that's an interesting question/suggestion. I think the reason for the change in the IRI-specific paragraph was to deal with path-relative reference being part of the URI syntax but the term is not used in the IRI syntax (which appears to use "rootless" instead). The current reference to section 6.5 of [RFC3987] is not completely informative (although it has some important elements, especially considering how all segments of an IRI are not necessarily treated the same, something that can happen for in-package paths and paths that leave the package). It is probably not a giant problem but Murata-san found the change to be agreeable in discussions with Michael. (Of course, Murata-san is only paying attention to IS 26300, etc.) We could avoid that change (for now) since it is technically not a fix that works directly for the ODF 1.0 OASIS Standard. Also, there is an item in the new list of defects that will raise the issue again. 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? 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. 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. 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. 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. -----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]