RE: [oic] ODF 1.1 compatibility / manifest:version in ODF 1.2

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

The problem is that it is some ODF 1.1 implementations that fail on reading those packages.  No one is going to fix those ODF 1.1 implementations.  It was not an ODF 1.1 feature.

There are also ODF 1.1 consumers that ignore new ODF 1.2 (and anything else not understood).  These fail in wonderful ways when the package really does carry some substantive ODF 1.2-unique provisions, such as AES encryptions.

I suspect some ODF 1.2 implementations will not produce it because they don't do anything in packages that needs it and they are not going to produce documents that their own earlier ODF 1.1 implementations still in use will fail on for no practical reason.

I assume that actual ODF 1.2 implementations will either require it or ignore it.  Will Gnumeric refuse to accept an ODF spreadsheet from Excel 2013 because it doesn't have that manifest attribute?  (The Excel 2013 Preview that I run produces wonderfully minimalist manifest.xml files that anyone should consume without complaint.)

 - Dennis

-----Original Message-----
From: oic@lists.oasis-open.org [mailto:oic@lists.oasis-open.org] On Behalf Of Andreas J Guelzow
Sent: Tuesday, November 06, 2012 11:27
To: oic@lists.oasis-open.org
Subject: RE: [oic] ODF 1.1 compatibility / manifest:version in ODF 1.2

On Tue, 2012-11-06 at 12:11 -0700, Dennis E. Hamilton wrote:
> As I was saying ...
> 
> How about when the specification is simply wrong?

How can the specification be wrong on this issue? It says that the
version attribute is required. The specification may be ill advised, but
I don't see how one can argue that it is wrong.

>  Would you not make advisories about that?

If the specification is underspecified, or contradictory, etc. I can see
that an advisory is justified, but said advisory should not contradict
the specification.

> Or a security problem with the recommended encryption?

I see no problem with an advisory regarding a recommendation or even a
'should'. But this is different from advising against following a
requirement. 

>  Would you not mitigate that, even if it meant going outside of the requirements of the spec?

The problem is that some implementations fail on reading the files with
this property claiming it is invalid, rather than saying that they do
not support the newer format or issuing a warning to that effect. Those
implementations should be fixed. There is nothing intrinsically wrong
with the specs regarding this issue.

> 
> I think pragmatism is valuable in these situations.  The idea is to foster interoperability, not create meaningless barriers and breakage.

If the pragmatism implies not to follow existing specifications, then
what is the point of those specifications in the first place?

Andreas


> 
> -----Original Message-----
> From: oic@lists.oasis-open.org [mailto:oic@lists.oasis-open.org] On Behalf Of Andreas J Guelzow
> Sent: Tuesday, November 06, 2012 11:06
> To: oic@lists.oasis-open.org
> Subject: RE: [oic] ODF 1.1 compatibility / manifest:version in ODF 1.2
> 
> On Tue, 2012-11-06 at 10:48 -0700, Dennis E. Hamilton wrote:
> > I would recommend something that the OIC can do within its sphere, and that won't happen very quickly, if at all, at the ODF TC:
> > 
> >  Recommend that ODF 1.2 consumers accept the package whether or not the attribute is set.
> > 
> >  Recommend that producers only produce that attribute if there is
> > something *about*the*manifest* that requires ODF 1.2 package
> > provisions.  That is, if additional provisions that are not in ODF 1.1
> > and earlier packages are relied upon, such as additional encryption
> > methods, etc.
> 
> I do not think it is appropriate for the OIC to recommend the creation
> invalid ODF files.
> 
> Andreas
>  
> > 
> >  I helped write that requirement and it was a mistake.  My bad.  Unfortunately, there are folks who think it is a good idea.
> > 
> >  - Dennis
> > 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: oic-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: oic-help@lists.oasis-open.org
> 

-- 
Andreas J. Guelzow, PhD FTICA
Professor of Mathematical & Computing Sciences
Concordia University College of Alberta