[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Comments on draft response
Dennis, I'd stick to technical observations on the substance of the comments for now, since this particular revision is not being proposed for an OASIS Approved Errata ballot at this time. Certainly, when we do have a vote at that stage, we'll need to fully follow the OASIS requirements for Approved Errata. But right now the document is in a form that makes it easy for us to solicit technical review by both OASIS and SC34. One we receive and incorporate such feedback, Patrick can produce the needed revisions to make this a proper formal OASIS deliverable. This will likely not occur until after the Ad Hoc 3 meeting. And then he'll have further work on the SC34 side to make it into a formal JTC1 deliverable. I believe he will be mindful of techniques that can be used to reduce unnecessary rework in that editing process. Also, as delegates to the Ad Hoc 3 meeting, I think it is important that we understand the technical details on each of these issues as well as the TC's position on each one (where there is an consensus). I'm thinking of get an extract of the discussion in JIRA for each of these issues into PDF format. I'll extract right before I head to Seattle, so I'll have the latest in case connectivity is sparse. Regards, -Rob From: "Dennis E. Hamilton" <dennis.hamilton@acm.org> To: <Michael.Brauer@Sun.COM> Cc: <robert_weir@us.ibm.com>, <office@lists.oasis-open.org>, "Patrick Durusau" <patrick@durusau.net> Date: 08/11/2009 12:50 PM Subject: RE: [office] Comments on draft response Michael, When we developed what is now Errata 01, I recall being told that we can only issue OASIS-published errata for approved OASIS Standards. That is why Errata 01 consists of Errata for the OASIS ODF 1.0 Standard, and neither IS 26300 nor ODF 1.0 2nd edition, which are not OASIS Standards. (It is my understanding that the mapping to IS 25300/ODF 1.0 2e, and the mapping to defect-report items, was done as a courtesy but it is not the material content of the errata document, despite how much that is all that matters to SC34.) If my understanding of this is correct, I would like to know what has changed since October 2008. 1. If this is meant to be an OASIS Errata document, the disposition of JP2-35 is inappropriate or incomplete or both. Also, I submit that for the OASIS ODF 1.0 Standard there is nothing to fix, at least not in terms of the solution the defect report would like to see. 2. If this is a proposed disposition report to SC34 and is about IS 26300 (i.e., not an OASIS Errata document), then I have no problem with it because it is not an OASIS Errata document. 3. I would have fewer concerns if this were an Errata for the OASIS ODF 1.1 Standard, assuming that the responses work there and there is an useful mapping to IS 26300 to satisfactorily dispose of the SC34-submitted defect items. Knowing which of (1-3) or some other flavor is the case is rather important in determining how to review the report. - Dennis PS: Aside to Patrick. In some cases, it is necessary to know the intended end-game in order to understand how to review a working document. I think the level of scrutiny required is quite different depending on which case (e.g., one of 1-3 above, or another) is intended. It certainly governs how much priority and energy I provide as a reviewer. I request your forbearance whether or not you share that concern. PPS: Now, I also have technical objections to the proposed solution in the case of JP2-35, since it does not take into account other constraints that apply and are not well-specified in the ODF specifications. That is why I think it is better to work this out with great care for ODF 1.2 Part 3 and then see how to reflect that in any errata for earlier ODF 1.x standards. I will raise my concerns in JIRA and in comments on the ODF 1.2 Part 3 working draft rather than on this thread. FYI for background, these concerns have to do with constraints on the Zip filename entry of a sub file, its relationship to manifest:full-path values for that sub file, if there is one, and other considerations around how a folder structure is overlaid on the collection of Zip sub files for the specific purposes of the OpenDocument Format. To be precise about this, I say it is also necessary to profile Zip in a way that determines what variations of Zip features are permitted for conformant OpenDocument Format document and which ones shall not be used. After or along with that, one needs to say how IRI features are reflected in the Zip filename for sub files and in the manifest:full-path value corresponding to those sub files. It is a requirement of the relevant URI/IRI RFCs that such a determination be made. It could even be the case that there is no need for special URI/IRI-encoding in Zip filenames and manifest:full-path values at all since these names are all produced via software and avoiding character-set encoding issues might be the best approach. If URI/IRI-encoding is provided, the considerations need to be extended to the unique ODF manifest provisions for manifest:full-path values (ending in "/") that project MIME types onto (some of) the ODF-defined folder structure and that do not have corresponding sub files in the Zip. There may be more and I believe the analysis must be done very carefully. -----Original Message----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] http://lists.oasis-open.org/archives/office/200908/msg00143.html Sent: Tuesday, August 11, 2009 00:14 To: dennis.hamilton@acm.org Cc: robert_weir@us.ibm.com; office@lists.oasis-open.org Subject: Re: [office] Comments on draft response Dennis, On 10.08.09 21:30, Dennis E. Hamilton wrote: > Here are some problems that I notice with this approach. > > > 2.2 Along with this, the JP-35 response refers to language (and section > titles) in IS 26300 that are not the language (or referenced IETF RFCs) in Regarding the different language: The wording of the two paragraphs in 17.5 we are talking about differs between the OASIS ODF 1.0 standard, and the OASIS ODF 1.0 2nd edition, which is the same as ISO 26300. The current draft lists the wording of the 2nd edition/ISO 26300. If that is the concern, we can a) omit the original language, and just refer to "the first paragraph behind the list in section 17.5", etc. b) include the text from the OASIS standard, with a note how this reads in the 2nd edition. Both suggestion should resolve that issue. Regarding the different RFCs: The OASIS standard contains a reference to §5 of RFC2396. The 2nd edition/ISO 26300 contains a reference to RFC3987, which turned out to be problematic. We are now resolving that by a dual reference to RFC3986 (which is the successor of RFC2396) and RFC3987. Why do you think this is an issue, in particular, since we are not referencing RFC3986 in general, but a specific definition in a section? > the OASIS Standard for ODF 1.0. This is no closer to resolving this one > than when the same defect was deferred in Errata 01. I disagree on that. I think the issues are technically resolved, and the editorial issue how to handle the situation that the text between ODF 1.0 and ODF 1.0 2nd edition differs should be resolvable as well. > I recommend that we continue to defer this item until we figure out what I disagree on that as well. We have deferred this in the first errata although we had a proposal how to resolve this. I don't want to defer this one more time. > we really want in the ODF 1.2 counterpart and then see how to reflect that > in any future errata. The current draft for ODF 1.2 already contains a rewrite of this section. However, that goes in my opinion beyond what I would like to change in an errata document. Best regards Michael -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering --------------------------------------------------------------------- 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]