Jirka Kosek <> wrote on 02/12/2009 09:58:26 AM:
>
> wrote:
>
> > However, I could give you equally plausible extension attributes which
> > would require entirely different processing, and in fact would lead to
> > horribly corrupted documents if the same processing rules were
> > indiscriminately applied.
>
> Indeed. But even if ODF will use the simplest policy that application
> should strip unknown extension elements/attributes this problem will be
> eliminated.
>
That is certainly one solution. But I think that is unsatisfactory to
application vendors who wish to extend ODF. I can certainly imagine
situations where we might want to add extensions to Lotus Symphony. But
we cannot assume a homogenous world where everyone runs only Lotus
Symphony. It would not be worth adding extensions unless we had some
confidence that they would not be stripped by every other ODF application.
But the general extension mechanism doesn't provide enough information to
allow even gross level preservation of extension data under common editing
manipulations.
This is non-optimal for the application writing the extension as well as
the application processing the extended document. The lack of a way to
define safe extensions -- and I believe most are innocuous -- will stall
the development and success of all extensions.
It is like airport security. Because they cannot figure out a way to
distinguish drinking water bottles from explosives, they confiscate all of
our liquids. The solution is not to stop checking passengers for
explosives. The solution is to find a good way to distinguish safe from
unsafe liquids.
> > Has anyone done this work already? I'm surprised there is not a
> > well-known standard for expressing such editing semantics. I think
most
> > of my concerns would be answered if we had a standard vocabulary for
> > indicating for extensions things like volatile="true",
> > preserveOnCopy="false", etc.
>
> I think that this task is very complex and AFAIK the completely general
> solution leads to NP-complete problem. Probably nothing what anyone
> would like to implement in his office application.
>
> Of course, the most typical cases could be handled by rules you propose.
>
The general problem is hard, as you state. But I think we would hit 95%
of uses by having a short list of attributes like preserveOnCopy,
preserveOnEdit, preserveOnMove, etc.
The key is to consider the Least Power Rule's "choosing the least powerful
language suitable for a given purpose". Depending on how you define the
"given purpose" you will get different results. If the purpose is purely
representational, how to encode extensions data at that's all, then you
end up with one solution. But of we acknowledge the context of ODF, which
by our charter is for office application "document processing and
interchange", then we need to consider more than just encoding in the
purpose. The purpose needs to consider interchange as well as processing.
So the question we should be asking is what is the "least powerful" way
to define extensions that work in that context?
-Rob
