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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] List Proposal Vote Deadline on Wednesday

On 5/2/07, Thomas Zander <zander@kde.org> wrote:
> I'm assuming with 'key' you mean list-id.

I meant it in the sense you used it orginally, which as I understand
it is the list-id. You said:


David made a good explanation on how we have a proposal that uses 3 keys
and another that uses 2 keys for each list item.
The logical conclusion is that a '2 keys' model can be emulated in the
3-key model.  Simply by keeping 1 key always the same. (insert 'duh'
here ;)

Or in other words; converting a WW document into a ODF document can be
done in the 'oliver/thomas proposal' by having all your lists use 1
list-id and having different styles for each list.
The conversion back is then easy as well.


> Anyway; I'm not sure its useful to go into the details here, it would be a
> technical discussion of a scope and size that many will walk away
> wondering what has been said.

Probably including me. :-) But how do you emulate a 3-key model in a
2-key model?

> The deadline has been closed; and I just checked to see that the vote is
> in favor of the proposal I and Oliver created. So I can continue my work
> on KOffice wrt lists, which has been stagnant for some months due to
> Florians proposal meaning I'd have to rewrite most of it.Happy thoughts
> that my many months of (volunteer) work is not for nothing ;)
Your choice. But unless I am satisfied fairly quickly that the vote
today does not foreclose full fidelity interop with MS Office, I'm
probably going to be doing things that may muck with your plans. As
things stand, my advocacy for ODF is at a standstill until the
technical issue of interoperability with MS Office is resolved in
regard to lists. This is far too important an issue to allow my
personal feelings toward you to get in the way of its resolution.

> I have to make clear that in my eyes (and I'm positive that Oliver will
> back me in that) there choice was not of interoperability or
> no-interoperability for the proposals. I believe that Florian has been
> using that as a weapon of doubt, but without grounds or research into
> that area.

What conceivable motive would Florian have for raising the
interoperability issue other than the fact that he can't find a way
around it? I'm mindful here that Florian has been fairly wallowing in
ODF-MS Office interop development work for quite some time. In fact,
he's part of the only development team in existence that is working on
full fidelity ODF interop with MS Office, so I'm inclined to take his
warning seriously.

I'm sure he was acting in good faith, but that does not change
> that the interoperability still has to be researched more before we can
> give a good judment on that.

Thank you for your candor. It's been a trait not encountered often
enough during my lifetime. But I do not understand why you pressed for
a vote on the lists issue without having resolved the interop issue
first. Is it that you don't see the business process interop with MS
Office use case as an important issue?

Let's assume for the moment that the research ultimately shows that
the Sun/KOffice list proposal vote does foreclose full fidelity
interop with MS Office. Would you then be willing to scrap the work
you do on lists in the meantime and fix the ODF spec so the barrier to
interoperability is removed? Please consider your answer carefully. I
am in effect asking whether we should hand Microsoft the ability to
say that ODF is non-interoperable with MS Office **by design.**
Microsoft is already saying that ODF is not rich enough to accomodate
their Office feature set. It's an issue I've looked at pretty
carefully and I have disagreed with Microsoft's claim up to now; but
shall we make it official that Microsoft is right and that we just
don't care about users who want a non-lossy migration path and full
fidelity interop?

> So, on both points I think its much more useful to dig into the code and
> work together with the choice that the TC has made. And when it appears
> we are incapable of full fidelity (which I seriously doubt) we should
> revisit this chapter).
> After all; good designs are created when your mouth is closed ;)

And buildings burn to the ground if no one calls the fire department.
:-) Do you have a particular date and time in mind by which this
question should be resolved? I've just lost about 10 days work to an
illness. Now most of my work is on hold because of today's vote. This
isn't an issue I'm presently willing to put on the back burner for
more than a very few days. I need to know whether we're all rowing in
the same direction. If we aren't, I need to bring some pressure to

I do appreciate you keeping the communication channel open.

Best regards,


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