[ODFPlugtest] MSO does not read LO files

[Dennis E. Hamilton]

Andreas,

 1. If I take this to the ODF TC it will be with a JIRA issue during the current Public Comment Period.  I want to avoid that.  I'd rather take an advisory to the OIC TC.

 2. I find it strange that we are penalizing any consumer that is strict about how it consumes ODF 1.1 Manifests while insisting that ODF 1.2 producers make such manifests for no meaningful reason than to check off a tiny conformance box, and penalizing the ODF 1.1 consumer.  We can do that.  I don't think it is a responsible, real-world approach.
    Remember, for most of its life, the ODF 1.2 Specification had no such provision as <manifest:manifest> manifest:version.  So it is not like there was some particular need for it.  It was an afterthought.  It apparently would not be missed if it disappeared entirely.

There is *nothing* in the ODF 1.1 specification that says how a manifest consumer is expected to be generous, or deal with tags and attributes and their values that are not understood and are not specified in ODF 1.1, no matter what namespace is used.  I'm pretty certain that there is nothing about that in ODF 1.2 Part 3.

 3. My recommendation is that the attribute be omitted *unless* there is something in the manifest that is essential and is not provided for in ODF 1.1.  That is, the manifest.xml is ODF 1.1 compatible.  The attribute is useful where ignore-what-you-don't understand would get a down-level consumer in trouble, such as failing to recognize additional attributes that apply to decrypting an encrypted document.  Of course, ignore-what-don't understand down-level consumers are going to ignore the attribute anyhow, aye?

I do think this is an useful topic for the Plugfest.

 - Dennis

PS: I don't know about other cases that Microsoft Office ODF 1.1 consumers might stumble over.  I stumbled over their stumbling over it completely by accident (it is a gift I have).  I just checked Windows 7 WordPad and it just opens the documents from OO.o 3.2.0 and LibreOffice 3.4.0 with a simple report that it does not support all features of the format.  It says the same thing for ODF 1.1 documents from all sources I have lying around.

-----Original Message-----
From: plugtest-bounces at opendocsociety.org [mailto:plugtest-bounces at opendocsociety.org] On Behalf Of Andreas Guelzow
Sent: Tuesday, June 28, 2011 13:21
To: plugtest at opendocsociety.org
Subject: Re: [ODFPlugtest] MSO does not read LO files

[ ... ]

As an implementor, if I am faced with a choice between accepting
"guidance" and violating the specification, I will have to follow the
specification.  As a member of the OASIS ODF TC I am absolutely opposed
to issue "guidance" that violates the specification.

> 
> The standard is too brittle in this place, with no added value and the
> downside of making documents that are so "valid" rejected by
> down-level consumers that will likely process the document just fine
> once it is "corrected."

Which consumers? I am only aware of one implementor whose product (any
version) is so brittle to stumble over this change.

> 
> I do not believe this was a well-considered change (even though it is
> there because I opened my big mouth).
> 
> Originally, manifest:version was defined only for use on a
> <manifest:file-entry> to indicate the version of the artifact that the
> file entry corresponds to. 

Your initial arguments that the manifest should have version information
still applies. Before we dropping the requirement of this version we
should really consider whether we can always live without version info,
or what exactly the absence of the version attribute means. 

[ ... ]

Does MSOffice stumble over this attribute or only over the attribute of
the name name to the manifest:manifest element?
> 

> OFFICE-2244:
> <http://tools.oasis-open.org/issues/browse/OFFICE-2244>
>  Provide Package-Level manifest:package-version attribute
>  *THIS IS ENTIRELY MY ERROR* 
>  ****How many times must I say this was a blunder?****

Why does the reasoning given not any longer apply. Are we sure that this
was indeed a blunder? [To me it still looks like that the choice made by
an implementor not to allow for future ODF versions is suddenly seen as
a problem for the specification.]

> 
> Here we made things even more brittle.  Nice idea in a self-evident
> sort of way. Terrible idea considering that it breaks down-level
> compatibility whether or not the document in hand will be processable
> just fine by an ODF 1.1 consumer were the attribute simply not used.
> This is not about what an ODF 1.2 consumer should do, but about the
> havoc introduced for no gain with respect to some ODF 1.1 consumers
> who take the ODF 1.1 manifest.xml schema as gospel.

Are we really sure that there cannot be situations where this version
attribute is important?

Andreas

> 
>  I doubt that this was ever discussed on the TC or noticed by a
> reviewer after it was introduced and first appeared in this form in a
> Public Review.
> 
>  The description in the issue states my concern.  I did not consider the down-level impact.
> 
>  (I don't know if anything happened about Michael's comment concerning the <dsig:document>.  I'm afraid to look.
> 

PS: I believe this discussion should really happen on the TC mailing
list.


-- 
Andreas Guelzow <aguelzow at pyrshep.ca>

_______________________________________________
Plugtest mailing list
Plugtest at opendocsociety.org
http://lists.opendocsociety.org/mailman/listinfo/plugtest