[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Public Comment #210 On Numbering
2.1 (my numbers) - I have no evidence that this is caught in the 1.2 changes from previous versions. In any case, I am not embarrassed to repeat the injunction as a reminder that it not be overlooked. 2.2 Obviously, not everything not defined in this particular standard is "intended" to be application dependent. There are times when affirmation through redundancy is powerful, because it moves something from oversight to "as designed." I have too many times thought there was only one way to interpret something and found myself mistaken by reality and surprising interpretations. Also, we make people work too hard by not providing the simply explicit versus a kind of catch-me-if-you-can indirectness and vagueness that has to be resolved by complex study. Not only does that part suck, it impeaches everything else we do. [I do understand the value of minimizing redundancy as a way to avoid contradiction. But that demands a high degree of rigorous attention and careful language as well.] 2.3 Sorry, I dropped a stroke. What I meant "to be accomplished" was offering a means for discovery of how a 1.x producer interpreted the feature under question, so that a 1.2 consumer could come up with the closest match through use of the 1.2 provisions. On the call, we were talking about identifying generator strings and somehow learning which producers applied which interpretation. That's the dot I didn't connect. 3. I think the question is whether or not I delimited the situation that is unsatisfactory for Florian, so he can say exactly what is still missing for him, or whether there is something in here that would satisfy the problem from his perspective and concern. I am not clear what he thinks the TC is empowered to do here, and I await his response. I don't expect the TC to every be in the bug adjudication business, so we are aligned on that. Whether vendors would voluntarily account for bugs, once discovered, so that products could work around the consequence in legacy documents is an interesting topic. That probably doesn't require TC involvement either. Producers can unilaterally introduce sufficient details in <meta:generator> "user agent" strings to help that out, it seems to me. - Dennis -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] http://lists.oasis-open.org/archives/office/200903/msg00088.html Sent: Monday, March 16, 2009 12:35 To: office@lists.oasis-open.org Subject: Re: [office] Public Comment #210 On Numbering "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 03/16/2009 12:24:40 PM: http://lists.oasis-open.org/archives/office/200903/msg00087.html [ ... ] > 2. POTENTIAL REMEDIES > > 2.1 Clearly, we need to make sure that the improvement in ODF 1.2 > is identified in the section on changes from previous versions. > I believe this has been done. > 2.2 We could acknowledge, in errata for ODF 1.0/1.1, that the > relevant part of the specification is underspecified and is > effectively left to be implementation determined. (This would be > essentially a confirmation of the consequences of what there is and > is not specified.) > Obviously anything that is not defined in the standard is application-dependent. The criteria for determining whether something goes into Approved Errata should, IMHO, be set somewhat higher than the desire to restate the obvious. I think it would be a waste of time to produce errata that merely take implicitly application-dependent text and indicate explicitly that they are application-dependent. Especially when the text can be interpreted no other way than being application-dependent. In any case, this doesn't really help Florian, since he knows it is application-dependent, as do all of the implementors on the TC. > 2.3 There could be an ODF TC technical memorandum on the > situation with suggested ways for implementations to accomplish > this. The ODF 1.2 specification could make a non-normative > reference to such a memorandum. > Suggested ways to accomplish what exactly? If ODF 1.2 tells how to do do numbering, then ODF 1.2 implementations know what to do. If existing ODF 1.1 implementations wish to be forwards compatible with ODF 1.2, then they can also implement what is specified in ODF 1.2. There does not seem to be any shortage of information here. > 2.4 There could be a Wiki where the handling of these list/ > paragraph numbering cases that applies for specific generators of > versions of ODF documents is registered. This would also need to > provide for the interesting case of newer generators producing down- > level documents (e.g., OO.o 3.0.x when configured to save documents > as ODF 1.0/1.1, resulting in their identification with > office:version="1.1"). The technical memorandum could also locate > the wiki page where this material can be located. > I'm not sure this solve Florian's issue either. I don't think he is looking for a way to document what he does with numbering. It sounds more like he is wondering what do to with other vendor's 1.1 documents. But we can't force them to document what they did. In theory we could speculatively put up such a wiki page and invite them to enter information. But I doubt any vendor has not provided this information yet because they couldn't figure out how and where to post it. So I'm not sure this solves the real problem either. Remember, we could also have bugs in ODF editors that cause them to write out documents which are not conformant. Bugs are application-dependent as well. But I don't think the TC should be in the business of tracking specific bugs and application-dependent settings and telling other implementations what to do with them. That might be a good thing for vendors to do on their own or via other organizations, like the ODF Alliance. But this would be entirely out of the scope of the TC's charter. Best solution might be for Florian to talk to the specific vendor that he has problems with and try to get more information. > 2.5 We could make a non-normative appendix that identifies where > these legacy-adjustment practices and similar glitches are > addressed. I don't think that is a great idea. I think the place > linked in the front matter with regard to errata should also find > technical memoranda, and the various on-line resources, such as the > ODF TC page, should point out their existence as well. > Still assumes that vendors actually see value in writing up this information for Florian. > 3. IS THAT IT? I hope so. -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]