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 Wednesday 02 May 2007 22:53:29 marbux wrote:
> On 5/2/07, Thomas Zander <zander@kde.org> wrote:
> > On Wednesday 02 May 2007 21:32:53 marbux wrote:
> > > > Bottom line; if there is a feature on ODF that WW doesn't support
> > > > (like the concept of one style being reused for different lists)
> > > > then don't use it and you can export just fine. Which means that
> > > > loading and saving a WW doc can and will be loss-less if you
> > > > write a good converter.
> > >
> > > I'm not competent to evaluate this. But I don't recall seeing
> > > anything in the Sun/KOffice proposal specifying what that single
> > > key is to be. It seems that what you propose might work if one were
> > > concerned only with KOffice <> MSOffice round-tripping. But think
> > > of the more involved use case where the same document gets handled
> > > by a bunch of different apps, say for example a MSOffice <> KOffice
> > > <> OpenOffice <> Google Docs round trip. In your scenario, does it
> > > matter that there is no single key identified in the spec to be
> > > used by all apps?
> > >
> > > The situation is far more complex than writing a converter for
> > > going between just two apps.
> >
> > That's a fair question; and I have to be honest that I have not
> > looked at all the corner cases here.
> > The concept I stated in the parent post is a simple one, though. It
> > basically states that we avoid using a specific feature because WW
> > doesn't have it. The following repeated loading and saving would
> > perserve our list-information (as normal) which means that, indeed,
> > the roundtripping via 3 different apps would still be possible. WW
> > loading the ODF file would be able to get all its list info back.
> >
> > The moment it fails is if the user starts using a feature that WW
> > does not have.  But I think that's a universal conversion problem and
> > not very specific to lists.
>
> But how is KWord to interpret the single key added by OOWriter if
> there is no agreed functionality for that key? I.e., will KWord render
> the list properly using OOo's arbitrary single key? And Zoho Office,
> and Google Docs, etc.? And what if the last app in the chain handing
> the document back to MS Office doesn't know what that single key
> means?
>
> Not trying to be difficult here. I'm just really concerned about
> interoperability with MS Office. It matters whether ODF is just a
> format for Sun and KOffice or is for everyone to use.

I'm assuming with 'key' you mean list-id.
I said in earlier mails on this topic that a list-id maps to a 
user-defined list. Which means that if the user defines all lists in the 
whole document to be one list, as WW does, then thats the scope of your 
list and thus you would end up with one list-id.

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.

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 ;)

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. 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.

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 ;)
-- 
Thomas Zander

PGP signature



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