[ODFPlugtest] MSO does not read LO files

Arthur Buijs arthur at artietee.nl
Wed Jun 29 09:10:59 CEST 2011


Hello,

just to make sure ... 

The next ODF Plugfest is two weeks away and will be held on July the 14th and 15th in Berlin.

This will be one of the many topics and it is an issue for everyone involved in ODF.

-- 
Regards/groeten,
Arthur Buijs



-----Oorspronkelijk bericht-----
Van: Doug Mahugh <Doug.Mahugh at microsoft.com>
Verzonden: wo 29-06-2011 02:15
Aan: ODF Plugfest mailinglist <plugtest at opendocsociety.org>; 
Onderwerp: Re: [ODFPlugtest] MSO does not read LO files

> Thanks for your feedback, everyone. We are indeed listening, and we're looking 
> into the issue. As has been noted, this is an issue for Office 2007 as well as 
> Office 2010, and it was caused by the addition of a required attribute after 
> those products were released, in a version of the ODF standard that those 
> products don't support, so it's not clear to me what can be done, but I'll keep 
> everyone posted. I agree that this would be a good topic for a future plugfest.
> 
> - Doug
> 
> -----Original Message-----
> From: plugtest-bounces at opendocsociety.org 
> [mailto:plugtest-bounces at opendocsociety.org] On Behalf Of Dennis E. Hamilton
> Sent: Tuesday, June 28, 2011 4:15 PM
> To: 'ODF Plugfest mailinglist'
> Subject: Re: [ODFPlugtest] MSO does not read LO files
> 
> 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
> 
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest
> 
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest
>



More information about the Plugtest mailing list