Ben Baston <bbaston@gmail.com> wrote:
> Though I accept your guidance that changing the current ODF treatment of extensions
> is an issue for the TC of which you are co-chair and so is off-topic in this Discussion,
> I do not agree that objecting to allowing IP-restricted or unknown features amounts to
> a manifesto. In fact, such behavior would amount to blatant roadblocks to interoperability
> should they be used - especially in the context of long-term and editable data preservation.
That's not really true.
While it's possible that someone could extend an ODF document
with "foreign" content, you cannot say a priori whether it is a road block to interoperability or not, and indeed disallowing such practice would be extremely dangerous.
In general, this new TC must act on the basis of good faith. It cannot outlaw what people will do with the standard, or prevent them doing "bad" things, and its role as a watchdog of sorts is something I would contest in any event - it is much more useful as a tool for vendors than some kind of quasi-W3C.
Foreign data is a great example, because you can use it for all sorts of good reasons. As much as anything else, it potentially gives you a way to downgrade an ODF document to an earlier version while still retaining the data in a separate namespace very simply and easily.
It comes down to the points I raised originally about carrots and sticks. A new TC will do its best when it encourages ODF interop and makes things work better together. Trying to prevent
"whoever" (let's be honest here ;) from "perverting" the standard is a lost cause and simply unproductive. Trying to restrict people to the "one true way" would actually serve to retard the progress of ODF.
The comparison with HTML keeps being made in such discussions. ODF is totally different to HTML. For one thing, few people author ODF - a few select applications do it. It is much more important for those applications to be authoring good ODF than it is to stricture ODF in such a way that you can validate documents and call them "good" or "bad".
Thanks
Simon.