Re: [office] List Proposal Vote Deadline on Wednesday

[Thomas Zander <zander@kde.org>]

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

PGP signature