Re: [tdf-discuss] Re: Do not support writing to OOXML format

On 1/2/2011 2:29 PM, Italo Vignoli wrote:
> On 1/2/11 8:15 PM, Barbara Duprey wrote:
>
> > Italo, one of the things that would make me (and maybe others here) feel
> > better about OOXML support is if writing to the XP formats causes LibO
> > to make compromises that do not have to be made going to OOXML. That is,
> > if documents developed under an ODF application can be converted to a
> > higher-quality product, in terms of compatibility of features and
> > formatting, when going to OOXML (even in the Transitional formats) than
> > they can when going to XP. Is that the case?
>
> Writing in a different format from the native one is always a problem, and causes a number of 
> compromises. The advantage of OOXML over the old MS proprietary formats is that is based on XML 
> and therefore is similar to ODF in the sense that is a "container" of the document components 
> (once you have unzipped the file, you get a number of folders and files with all the contents). 
> The better choice is always the native format, though, and we will always promote this choice.

It would be good to know which works better for interoperability when sent to an MS-only shop -- ODF 
or the current OOXML. In other words, is the LibO version of OOXML a better product than the MS 
version of ODF? Very interesting, if so. I'd like to know which to recommend. And of course the 
Sun(free)/Oracle(not free) plugin for MS Office is a player in this question, too. I know it's 
better than the MS ODF, but how does it compare to the LibO OOXML?

> Writing support of OOXML is important for interoperability, which is a key user requirement. I do 
> not know if writing OOXML has a higher level of compromises than writing in the old MS proprietary 
> formats, because I am not a technical expert and I trust on developers and engineers for these 
> issues. I suppose that there are different compromises.

I guess the key issue is whether this writing should essentially be given LibO's official sanction 
(that is, by being included without reservation in the SaveAs dialogs, and in the Tools > Options 
settings for defaults), or simply available as a deprecated format when forced into it. I agree that 
sending back an XP format given an OOXML one is likely to cause problems for LibO (that seems to be 
what OOo does, opening them as Read-Only with an XP extension and a constructed name that has no 
relation to the original). I would definitely be against removing the capability to write those 
formats altogether; but the official sanction of them does not seem necessary.

> I know that OOXML is a Microsoft format with many problems. I have been involved in the entire 
> standardization process, and I was against the standardization of OOXML.
>
> But once the standard has been approved, I have stopped fighting the document format, because I 
> think is more important to direct my efforts towards user requirements. Please remember that TDF 
> will strive FOR and not AGAINST, and this is a typical situation where if you are FOR user 
> requirements you have to forget that you are AGAINST OOXML.

In my view, the user requirement is for the best possible interoperability. So I'd like to know what 
that is -- and there still seems to be a possibility that for new documents constructed in LibO, 
writing the XP formats provides better interoperability than writing the OOXML ones. That's not a 
FOR or AGAINST issue, it's a matter of product quality. Giving a SaveAs choice for the OOXML format, 
indicating that it is for recent Office versions, definitely leads people in the OOXML direction 
whether that has better interoperability or not. If it does, so be it -- though I'd still like to 
see a warning that it's not really an open standard. If people are in an environment that encourages 
or mandates use of open standards, this isn't one!

> FOR is always stronger than AGAINST.

--
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***