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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

Subject: Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form

--- On Fri, 7/11/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, July 11, 2008, 1:28 AM
> 2008/7/11 Peter Dolding <oiaohm@gmail.com>:
> > Next is a non Wild West Method.  You can still create
> what ever
> > foreign keys you like.  Only limit needed added to 1.5
> For extensions I favour the requirement that when a user
> invokes a feature
> which creates an extension, he/she is warned about it?
> "Hey, this will extend the standard" or
> something.
> That way you know what you're doing? No excuses.
> Sometimes the feature
> will be needed, but it's a user choice. No more vendor
> lock-in by the back door.

Well, yes, user control and knowledge should guide decision-making as much as possible.

As relates to earlier comment, "bad" extensions would be good if the user wants them. I was trying to perhaps consider a guide for a "best practice" for apps to follow. To repeat then, a "good" extension/tag was informally defined as one that was well documented. [with this, I don't mean to suggest this concept be added to ODF]

I like the idea of making it easy to have identifying sigs for extensions to help identify the apps that added the content.

And While at it use sigs to identify app/authors even for standardized portions of the document [so, roughly, hash on the relevant content plus the author info]. Probably the sig framework in progress will cover this use.

This way you have even more trustworthy information to go on to help you decide if to trust or not.

BTW, without the authentication sig, apps should probably also still use whitelists. This can happen unofficially or a third party of some sort would host the information (eg, freedesktop or OASIS or someone totally different).

..and the fall-back plan (for me anyway) would be do dump foreign tags by default (not on a whitelist). This use case should be held in high regard by those creating conformance statements and test suites.

My ideal ODF would allow for maximal user control: the user sets the settings/ picks the profile/ and then standards-based mechanisms take over to conform to those wishes.

User control: +1. Standardizing *the range of user wishes* (eg, as you, Dave, expressed above would like): +1, to help interoperability. Seeing this actually happen within the next 2 years in part through the work of this TC: priceless.


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