On Wednesday 02 May 2007 20:03:45 Gary Edwards wrote:
> Let me also state for the record my that primary concern with the list
> proposals has nothing to do with the "compatibility with existing file
> formats - round trip" issue - important as that might be to internal
> plugin converters and translators. My primary concern is that there is
> something fundamentally wrong with a proposal where an application
> specific implementation method is having to be hard wired into the ODF
> specification - requiring other ODF ready application to embrace the
> new list implementation model if they want to fully participate in ODF
> document exchange chains.
I'm not sure I follow your reasoning here.
The basic concept of ODF is
a) we provide a way to encode a document and its structure using XML.
b) we provide a description of what xml tags mean and how they are to be
interpreted.
I.e. loading and saving.
If we want a users intention that paragraph X has counter with a specific
number to be encoded into an abstract xml-tag we have to make very clear
on how to interpret that tag so others will understand the concepts
behind it, and come up with the same number.
Then it follows we have to design a generic model, a conceptual idea,
which is used to explain the numbering to implementations reading the xml
So; part of what you are saying can not be avoided. You have to 'hard
wire' some concepts into the ODF standard. If you don't, the only
alternative is to explicitly state which number goes with which
paragraph.
Another part of your statement is incorrect; there is no requirement to
copy the designs and concepts that ODF provides. The application just has
to understand them.
Or, in other words. Consider I give you a message that a Chinese women
named "Ms Lee" was asking about you. To make use of that information you
have to understand that Chinese have their first and last names reversed,
so you don't go looking for the wrong person. That concept has to be
understood to understand the message. But there is no requirement to
then also redesign your address-keeping application. You can
just 'convert' between one model and another.
So, in short; the models and concepts ODF provides are meant for
understanding and interpretation of the spec. They do not have to be
hard wired into implementing applications to offer full support.
> This vote is a clear statement as to what the ODF 1.2 TC believes to be
> important objectives. The Sun/Koffice list proposal is a tradeoff,
> offering what is no doubt a very cool and innovative approach to list
> implementation, but at a cost to "compatibility with existing file
> formats. The Novell proposal attempts to let us have our cake and eat
> it too. Personally i really like the fact that Novell approaches the
> problem at the "flexibility" layer, trying to preserve our fabled claim
> that ODF is application independent.
I think that opinion is based on misunderstandings of the technical
aspects of these proposals. The biggest of those I addressed above and in
another mail.
Thanks for your thoughts!
--
Thomas Zander
