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

[Radoslav Dejanović <radoslav.dejanovic@opsus.hr>]

Dave Pawson wrote:
> 2008/7/11 Peter Dolding <oiaohm@gmail.com>:
>> Getting the non Wild West Method keys is not a long process.
> 
> It's not proved workable Peter IMHO. People don't like central registries?

Generally speaking, they don't. But, we're talking about a standard,
something that does imply to some point that there is central authority
to decide what goes into standard and what doesn't. I, for one, would
rather like to see standard being tight and controlled, much more than a
standard that is loose and everyone can modify (read: embrace and
extend) it. If I'm using the standard, I want to be sure that other
party use exactly the same set, that's the only way the information
won't get garbled or renderes incompatible in the process.

I think Peter's idea about registry of allowed keys is quite reasonable.
While you're right to point out that everything is prone to abuse,
having a central, "official" repository with rules that everyone has to
obey is harder to abuse than having no central authority on the matter.

There's one more thing, though. We're all talking much about different
vendors "tainting" the format with their proprietary extensions. IMHO,
the real fight for customers will be about the ease of use and
flexibility of applications, and that doesn't have to even touch the
structure of ODF. For an example, take a look at OpenOffice.org
extensions (http://extensions.services.openoffice.org) - little add-ons
that make your work more productive and/or easier, yet as it seems none
of them alters the structure of an ODF document(*) - and that is the key
point here.
I might be jumping to conclusions, but it seems that there will not be
that much interest in extending the ODF format per se, but in extending
the features of applications that use it. Therefore, number of
extensions *to ODF* might not be that great, and it would definitely be
manageable by a central authority, and that increases manageability of
compatibility further, since small number of extensions to format are
not a problem. For application extensions (such as those of OO.o), I
say, let that be an issue for developers of those applications, that
really doesn't have anything to do with ODF.


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

I wouldn't bet on customers. They don't care, they just want to get
their work done. If it is done by using non-standard extension - well,
to hell with standards! A warning is not a deterrent - users will simply
ignore them, and software vendor can simply omit such warnings,
especially if the incompatible feature is made by that vendor - and
there's nothing you can do about that. This really isn't a solution for
vendor lock in, because if you have a vendor of "Some Office" that made
nice but incompatible extension to "Some Office", and at the same time
it just happened to be that majority of people use "Some Office", you
have an instant lock-in.
People would simply ignore warnings because it makes their work more
productive, and since they're the majority, who cares about users of
less known applications?
And again, "Some Office" will not display a warning box because there's
no force of this world that would force them to warn their users that
there's a compatibility problem with that extension they've made.


(*) There are few extensions that insert a new function in Calc, and I
haven't tested out what really happens with ODF file in that case; if
nothing happens, thats fine - if the ODF gets altered, that's a nice
real world example of what we're discussing here...