<> wrote on 01/18/2011 03:43:28 AM:
>
> There is one thing which needs thinking. If a vendor implements a
> feature as described in a CSD and releases the software using the
> features there will be documents which use that feature. When then
> later the feature is changed in a incompatible way applications that
> don't support the CSD will not be able to show the document
> correctly which is very bad for interoperability.
>
> What do others think about that?
>
This is true. But the alternative proposals are also poor for
interoperability, such as using a non-ODF namespace. The real problem is
when an implementation writes a document that does not conform to
non-extended ODF. Whether this is done by vendor extensions, or by
implementation of a draft version of ODF that then changes, or due to a
bug, or whatever, the effect is the same. If you are writing out markup
that others do not understand, or which they understand differently, than
you have this problem.
No amount of syntactic sugar around version attributes will solve this
problem.
But one way approach to dealing with this issue is to raise the bar for
what gets into an approved CSD. In other words, give it sufficient
scrutiny so that we have high confidence that once a CSD has been approved
that the feature will not change in major ways. I'm not speaking
absolutes, but a commitment that we will not approve a feature
unless/until we have a high level of confidence.
In other words:
1) We have no control over what vendors implement and when they implement
it and what they call it.
2) Merely renaming things is obviously syntactic sugar and has no real
effect
3) The only thing we as a TC control is the contents of a specification
and whether it is approved as a CSD.
So I suggest that we apply ourselves to where we have the most direct
influence.
-Rob
