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

2009/2/17 Thomas Zander <T.Zander@nokia.com>:
> 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.

If it is as essential as you say, it seems reasonable to request it be
added to ODF.

> With ODF1.2 having been feature frozen for a year or so,

except where the two leads deem it not to be so. They define frozen it
would appear.

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

You request all apps pass this extension XML on, unmodified?
To me that defines 'special' treatment, i.e. an exception.

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

No problem at all with that. It is (your application) specific and will break
if the ODF file is passed via another ODF app.

My issue is with you asking all ODF applications to pass on your
'special' markup
unchanged. That, IMHO, is way out wrong.

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

Two different issues. This thread addressed the former..
"Non-defined information to store in a file" I'm taking to be
an ODF file containing extensions.

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

In which case I mis-interpreted your first mail, I took it to mean
you wanted *all* ODF apps to save your extension data.


Dave Pawson
Docbook FAQ.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]