Thomas Zander <> wrote on 02/12/2009 11:31:52 AM:
>
> Afterall, putting my properties in a the app-specific data or in
1.2-metadata
> makes it just as much of a black box as putting it directly in the tags.
They
> are just as hard to manipulate by 3th party implementations and those
have no
> idea when the properties should be removed of modified or duplicated.
But
> your policy would make *that* a legal way of extending ODF allowing an
> implementation to still be called 'pure' while a more readable version
with
> exactly the same bad interoperability will not be.
>
I'm trying to balance the various interests, that's all. There are people
who want to extend ODF. OK. Let's define a way to do this well, but in a
way that extended data can be preserved during editing. You won't get
high value uses of extensions without that capability.
I also hear that some people want no extensions at all in an ODF document.
If that's what they want, then let's define a strict conformance class so
those users can more easily specify their requirements when procuring
software with those specific capabilities.
But I'm not sure I hear a constituency asking specifically for an
extensibility mechanism that can never be better than a throw-away. And
if someone did want that, it could be just as well defined using less
powerful extension mechanism. Does anyone lose by moving toward a
better-defined extensibility model? I don't want to leave anyone out. But
honestly I see a move like this as a win-win situation.
What am I missing here? Is the concern about the forwards compatibility
of ODF 1.1 documents? Or the ability of ODF 1.1 processors to read ODF
1.2 documents? Something else?
If we do come up with a better mechanism, such as some extension data
processing attributes, we could apply those to the RDF metadata as well.
As you point out they have the same issues.
-Rob
