Re: [office] List Proposal Vote Deadline on Wednesday

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Gary,

there are a few thoughts in your mail that I would like to comment.

Gary Edwards wrote:
> I believe David and Thomas have correctly stated the case.  There is 
> however one aspect missing from their analysis; the "round tripping" aspect.
> 
> Thomas is right that the decision between the Novell and Sun/KOffice 
> List Proposals comes down to a trade off between an advanced list 
> implementation model two primary ODF applications have agreed to 
> implement, and, compatibility with existing file formats. 

While it is not entirely wrong to call the two proposals the "Novell"
and the "Sun/KOffice" proposal, I think it is a little bit unfortunate
to call them this way. Our TC consists of many experts. They of cause 
all work for a certain project or company. However, I believe that they 
all have their opinions not because they work for a certain 
project/company, but because of their expert status. I therefore think 
it would be more correct to use the names of those who work on a 
proposal, than their affiliation.

I further believe that the "compatibility" with existing file formats 
is, if at all, only one difference between the proposals. Other 
differences exist regarding the backward compatibility with ODF 1.1, and 
regarding the separation between content and style - a requirement that 
our charter explicitly mentions. The later two actually were it that 
influenced my own vote regarding the proposals.

And a third remark: We have seen a long and controversial discussion
regarding lists. This may lead to the impression that there are major
differences between the two proposals, or that they mean major changes
to the list representation. Both in my opinion is not the case. Large
parts of the specification for lists will not be changed by either
proposal. They remain as they are in ODF 1.1. The modifications both
proposal make to lists are minor ones. They effect corner cases only.
Corner cases that seem to occur seldom enough in real life that nearly 
no one until now noticed that ODF currently does not cover them. The 
representation of usual lists is not changed by either proposal.

This means, while there are differences between the proposals, otherwise 
we won't have two of them, we in my opinion must be very careful to not 
over-evaluate the impact they have. On "compatibility", but also other 
aspects of ODF.

The changes both proposals make to numbered paragraphs are a little bit
larger, because their possibilities were limited compared to lists in
the past. However, since they get closer to lists and because one has
the choice between lists and numbered paragraphs, this, at least in my
opinion, won't change the overall situation either.

[...]

> 
> For internal MSOffice ODF plugin converters, the Sun/KOffice list 
> proposal is a killer.  Same for the MS-CleverAge-Novell Translator 
> project.  They will be able to produce ODF 1.2 documents (with the 
> Sun/KOffice list model) without problem.  What they won't be able to do 
> is load (convert back to the in-memory-binary-representation) ODF 1.2 
> documents with the Sun/KOffice list model.  Any list structure in these 
> documents would break.

To be honest, I can't follow this. Some ODF 1.1 implementations already 
have Microsoft Word filters and support the roundtrip of lists. As said 
above, the modifications both proposal makes to lists are minor ones and 
the representation of usual lists is not changed by either proposal.
Because of that, I can't see how either proposal can largely change the 
situation

[...]

> 
> 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.  If applications are unable to innovate on top 
> of ODF, and have to turn to the TC to hard wire into the spec their 
> innovative implementation methods, then we have a serious flexibility 
> problem.  More serious than just lists. 

Can you explain which of the two proposals in your opinion adds an
application specific implementations method to ODF? Lists in ODF are
based on HTML lists. That's the case for both proposals. The differences
are how separate list blocks are combined to a list, and how styles are
assigned to a particular list item. My understanding of Florian's
proposal is that it is close to OOXML in this regard, while
Oliver's/Thomas' proposal is using a new method, that is not implemented
by any application. So, I won't go so far to say that Florian's proposal
is application dependent, but if we compare the application dependency
of the two proposals, then to me Oliver's/Thomas' proposal reaches a
slightly higher level of application independency than Florian's 
proposal does.
However, as I said above: We are talking about corner cases. Anything we
discuss regarding lists does not effect the usual lists we find in
documents. So we really must not over-evaluate the differences.

Having that said: I don't know who said that, but is is of course also
true that the ODF specification implies algorithms that have to be used
for numbering. Otherwise the result of numbering list items would not be
deterministic, and we would not meet the user expectation. However, we
must not make the mistake to call this application dependent.

> 
> In the end, i'm very happy to have the TC go on record having considered 
> every angle of this issue imaginable.  That's as it should be.

I agree to that. The ballot has closed now. This means, the ODF 1.2 
specification will contain some clarifications for lists and will add 
some new capabilities for lists and for numbered paragraphs. That's in 
my point of view far more important than the questions whether this is 
achieved by proposal (A) or (B).

Best regards

Michael
-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering