[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] The Rule of Least Power
On Monday 16. February 2009 18:17:28 ext Dave Pawson wrote: > > Therefor I think having this information saved even in an 'strict > > conformance' mode does not harm anyone and only helps the user not loose > > part of his work, which is really critical for using ODF as a native > > format for professional vector editors. > > So make one exception? Not reasonable for any app that doesn't use this > data? If the data is that critical it should be part of the document, not > an extension. I never said I don't want it in the ODF spec, it just is a fact that it is not in the spec and I the implementation still needs to store this data somewhere. With ODF1.2 having been feature frozen for a year or so, that there is something KOffice wants to store but is not in the spec is not all that surprising and IMO this will always be the case as we don't want to add every silly thing into the spec. > > In conclusion this one example falls between the two usecases. No > > government will care at all that this extension is there and forcing > > KOffice to not save it will just harm the user that uses the same app for > > re-editing. > > What makes this one use case for one application so special? I don't understand the question; I never claimed it is "special"... > > The more I read this thread and ask questions, the more I get the > > impression that the only reason this proposal is made is out of unfounded > > fear. > > No, just conformance to a 'standard'. Not a standard with a couple > of extensions just for application X You missed my point; the point is that nobody here has been able to claim why its an issue at all that implementation-x saves some properties only implementation-x is concerned with and implemention-y will have zero problems with. The bottom line here is that somehow people seem to conclude that having non-defined information to store in the file is a fitting way to determine non-conformance. While completely ignoring the much harder to-check problem of verifying that implementations actually honoring the odf-specified properties. > > In reality applications will be chosen based on which subset of the > > features of ODF they support, both loading+displaying and saving them. > > If your app saves the extension data and it's re-opened in the same app, > then nothing is lost. Only if it goes via a couple of other ODF > processors. That's the price of standardization. Thats what I was saying in my mail as well, and this is fine. The fact that extra-information is lost is not an issue for us and certainly not a reason to change the ODF specification. -- Thomas Zander
This is a digitally signed message part.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]