[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] List Proposal Vote Deadline on Wednesday
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]