[odf-discuss] Does OO.o violate OpenDocument? If yes, where?

marbux marbux at gmail.com
Sat Nov 18 05:36:37 EST 2006


On 11/18/06, M. Fioretti <mfioretti at mclink.it> wrote:
> I agree. The original question I quoted, however, came from a
> discussion "limited" to OO.o <=> ODF. In that context, that is if you
> only create ODF with OO.o, you *are* guaranteed (by definition) that
> you won't introduce "ODF features not fully supported", right? In
> other words, does OO.o behaves "creatively" in some cases?
>

I think the real problem is a fundamental flaw in the analysis of the
person who wrote the comment. Here is the statement again:

>>>
> "since OO.o doesn't support all of ODF yet (1), today distributing ODF
> files made with OO.o isn't at all a feasible solution for
> "distributing documents in an advanced open standard like ODF".
>
<<<

The author's premise is clearly stated: "since" OO.o does not support
all of ODF yet ... "

The corollary of the author's premise is that a distributed document
would have to include markup for every feature ODF supports. But if
you have a simple document, including markup for every feature ODF
supports would produce a file that is mostly cruft. That isn't the way
it works in any file format that I've ever looked at. E.g., if I am
manually creating an HTML document in a plain text editor and I don't
have any text that I want to appear in bold face, I don't insert any
<strong> tags.   I don't add any markup that isn't necessary for the
document I am creating.

Likewise, if OOo or another app implementing ODF is used instead of
writing a document in HTML, the app is not going to insert any bold
tags unless the author performs an action that will insert the bold
tags for him. A WYSIWYG editor like OOo is just substituting a
shortcut like Cntrl+B to create the same kind of bold tags that could
be created manually in plain text. If you don't initiate such an
action, the file will not include any bold tags.

An ODF document that does not use every feature that could be
implemented by a an editor that fully supports ODF is still an ODF
file.  Just so, an application does not have to support the full
feature set to produce ODF files.

So long as different ODF editors do not destroy document processing
metadata, e.g., bold tags, inserted by another editor that had edited
the same document earlier, a compliant application does not have to
support the full feature set. E.g., a compliant editor (editor 2) does
not have to support text attributes like bold face, so long as it
doesn't delete bold face tags inserted in the same document by another
editor (editor 1), just because editor 2 does not support the feature.
It is still an ODF file.

The author seems to have in mind that every ODF file includes a
registry identifying all of the features the generating app supports.
If you want to try visualizing his fantasy, maybe it would be a card
listing all of the features that the ODF specification supports and
unless a hole is punched beside each and every feature, it is not an
ODF file.

I suspect that the author doesn't know very much about file formats,
is being deliberately misleading, or experienced a temporary brain
malfunction. Or all of the above. :-)

Best regards,

Marbux



More information about the odf-discuss mailing list