OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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 

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 
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 

> > 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]