OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [opendocument-users] simple OO.org document goes awry in MS Office 2007 w/SP2 - what went wrong?


On Wed, Jun 17, 2009 at 7:46 AM, Michael Stahl<Michael.Stahl@sun.com> wrote:
> hi Paul,
>
> marbux wrote:
>>
>> On Tue, Jun 16, 2009 at 4:47 AM, Michael Stahl<Michael.Stahl@sun.com>
>> wrote:
>>>
>>> hi Paul,
>>>
>>> marbux wrote:
>>>>
>>>> If we are to lend credence to both the earlier and later
>>>> statements, one might infer that KDE and Sun worked out their interop
>>>> issues at the application level but didn't go to the trouble of
>>>> submitting corresponding proposals to fix the spec so others could
>>>> benefit from the knowledge they gained through their collaboration.
>>>
>>> this claim is demonstrably false.
>>> see e.g. "Proposal to enhance and clarify lists" by David Faure, Thomas
>>> Zander and Oliver-Rainer Wittmann:
>>>
>>> http://www.oasis-open.org/committees/download.php/23418/07-04-05-proposal-lists.odt
>>
>> Sorry, Michael, but you're wrong. I remember the "List Enhancement
>> Proposal" well because it was hugely controversial on the TC. It only
>> affects a few edge cases on ordered lists, or at least that's what
>> Michael Brauer said. He also admitted that it was a trade-off between
>> features and compatibility, with compatibility the loser.
>
> my point was that there is an instance of a ODF proposal with authors from
> both the KDE and OOo projects, falsifying your claim above that such
> proposals do not exist.

If you were responding to what I had said rather than a
mischaracterization of it, you were identifying the Sun/KDE proposal
as an "interop" proposal. It wasn't and it ain't an interop proposal.
It was a proposal to break interop so KDE wouldn't have to develop a
converter for its legacy documents.


>> The problem was that because of an ambiguity in the spec, KWord had
>> implemented ordered lists differently from OOWriter. The amazing fix
>> that Sun and KDE came up with was to allow implementations the choice
>> between using list tuples or list triples. This was so KDE wouldn't
>> have to write a converter for their ODF 1.0-1.1 documents.
>
> not true: the 2 ways of representing lists (list/list-item and
> numbered-paragraph) were already in ODF 1.0

Odd  that no one brought that up when everyone was saying that the
problem originated in an ambiguity in the spec, the charges were
flying that the proposal broke compatibility with earlier versions,
and Sun's Michael Brauer admitted that the proposal broke
compatibility between ODF 1.2 and earlier versions of the spec. Can
you provide citations for ODF 1.0 allowing both ordered list tuples
and ordered list triples?  And explain how it was not an
interoperability breakpoint if it did?

>
>> But it was anything but an interoperability fix. Consider that we'll
>> now have some apps apps out there expecting list triples and others
>> expecting list tuples. Now think about a processing chain where the
>> next app to process the document is unpredictable. One can map list
>> tuples to list triples, but going the other direction doesn't work so
>> well.
>
> given that both representations are valid ODF 1.0, this is not exactly a new
> problem.

Valid only because of ambiguity in the spec. And you're darn tootin'
that this is not exactly a new problem. The TC solution to create an
option between ordered list tuples and list triples and let the
implementers create work-arounds is a sterling example of just how
indifferent the ODF TC is to interoperability. Certainly it does not
help argue the position that the ODF TC fixes interop breakpoints in
the specification when they're brought to its attention. Nor does it
say anything about how well implementers do at bringing spec.
ambiguities to the attention of the TC.

During my time on the TC before I gave up efforts to reform it in
regard to interop from within, I saw many new interop breakpoints
being created in ODF 1.2, perhaps most notably Sun's proposal to allow
it to trash conforming xml:id metadata that was duly rubberstamped by
the ODF TC over strenuous objections on interoperability grounds.

>> So we got a work-around to avoid KDE having to write a converter for
>> its legacy documents, a break in compatibility with ODF 1.0/1.1, and a
>> break in compatibility between ODF apps and MS Word, which does list
>> tuples. That wasn't exactly good news to the Foundation developers who
>> were developing ODF plug-ins for MS Office that could round trip
>> between the Microsoft legacy formats and ODF without data loss.
>>
>> Short story: That was not an interop fix and it says more about the
>> ODF TC's indifference to interoperability than anything else.
>
> huh? personally, i had no problem implementing numbered-paragraph import in
> OOo, given the clarifications in the proposal which made the job a lot
> easier.

Oh? Let's hear your explanation of how interoperability can be
achieved in the following processing chain, where "list-tuple"
represents implementations that support only ordered list tuples and
"list-triple' represents implementations that support only ordered
list triples:

  list-triple < > list-tuple < > list-triple < > list-tuple < > list-triple

My addled brain says one can map from list tuples to list triples but
not in the other direction without data loss. Please explain to me why
I am wrong.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]