RE: [oic] odf 1.2 part 3, packages, features

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

Svante asks a good question.  I was thinking of the separation between Part
1 and Part 3 and the degree to which it can be kept clean.  

Here is more on how that looks to me as I conduct detailed review of the ODF
1.2 Part 3 cd01 Public Review document.

There is an effort to have Packages be useable separately from the rest of
the ODF specification.  That is, the documents and subdocuments in a package
that conforms to ODF 1.2 Part 3 cd01 need not have anything to do with ODF
1.2 apart from being conformant packages.

So I would think that the package-exclusive features are the only ones we
can deal with as features of the package specification.

DETERMINING WHAT PACKAGE-EXCLUSIVE FEATURES ARE

Clearly Package-Exclusive:

Although I think there is still some clean-up needed, the
META-INF/manifest.xml file that is all about the package and not the
document is clearly a feature of the ODF 1.2 package.  Other
package-specific features are the mimetype file.  These are clearly all
about the package and are without prejudice to the sort of documents and
subdocuments there may be in a given package.

1. Files that are excluded from the manifest are presumably part of the
exclusive structure of the package.  Those files are (1) any thumbnail file,
(2) the META-INF/manifest.xml file itself, and (3) any other file whose
full-path name in the package begins with "META-INF/".

2. The encryption methodology that is specified as part of the package
specification is tied into the META-INF/manifest.xml file.  Only those files
listed in the manifest can be encrypted, with the explicit special exception
for Thumbnails/thumbnail.png.  It is to be presumed that, in fact, all of
those files but for any Thumbnails/thumbnail.png are to be encrypted as part
of a package encryption.

Varied Package-Exclusivity:

There are additional provisions in ODF 1.2 Part 3 that have varying degrees
in which they are package specific and neutral concerning the documents that
are represented in the package:

3. The Thumbnails/thumbnail.png file is included in the ODF 1.2 Package
manifest and it cannot be produced without some understanding of the nature
of the document carried in the package.  However, it is excluded from
encryption and an encryption process should either remove it or replace it
with a neutral image used for encrypted packages in a way that discloses no
information beyond the fact of encryption (which is apparent by inspection
of the META-INF/manifest.xml file in any case).  So,
Thumbnails/thumbnail.png is provided for, and it can be used without other
knowledge of the document, when present, but it presumably can't be produced
without knowledge of the document being represented in the package.  So the
Thumbnails/thumbnail.png is very much the business of a document-aware
package producer.

4. The Digital signatures are a bit of a problem.  They are not included in
the manifest, so they may not be encrypted.  This raises the problem of
potential information disclosure that could be used to defeat the encryption
and/or identify the file as a worthy target for attack on its encryption.
In addition, digital signatures are presumably applied to transforms of
unencrypted files of document and sub-document representations.  There are a
number of difficulties concerning document-unaware signing of package files.
It may be that the only kind of blind signature is a kind of notarization
signature and not one that attests to anything else about the document.  I
suppose this is a worthy case for exploration further and 1.2 Part 3 will
need to elaborate on that.  I expect that various authorities will provide
additional profiling of acceptable encryptions (by this or some other means)
along with prohibitions of unacceptable encryption methods for materials
subject to those authorities.

5. The metadata manifests are a bigger problem.  There is nothing in the
conformance requirements for packages concerning metatadata manifests.  They
are clearly listed in META-INF/manifest.xml, and they are subject to
encryption.  
   This seems to be very much an optional facility and there is currently no
explanation for how it works and for how a manifest.rdf file, or
subdocument-path/manifest.rdf file is recognized and what if anything a
package-level service should do with it.  
   I suspect that the package-specific provision of metadata manifests is a
convenience for support of an as-yet-undescribed-in-Part-3 convention.  The
metadata manifests, it seems to me, are those files by which RDF files
carried in the package can be discovered and analyzed by software that is
otherwise unaware of the details of documents and subdocuments.  More work
is needed to establish this.  To ensure that this reserved convention is
being used in a package, it would be useful to have an agreed MIME type for
the metadata.rdf file, as well more information about the convention to the
extent that consumers of packages can count on it.  Producers should
certainly be prohibited from producing package files with the name
metadata.rdf that do not conform to the convention for ODF 1.2 package
metadata manifests.  If there is some requirement that this option be the
exclusive avenue for introduction of RDF metadata into ODF 1.2 document
packages, that should be established in ODF 1.2 Part 1, it seems to me.  
      For the current ODF 1.2 Part 3 cd01 Public Review draft, this is very
much an undocumented feature. What consumers should do with these and the
metadata files that they are manifests for is clearly not something for
which there can be much package-exclusive guidance.  At the package level,
whatever is listed in the META-INF/manifest.xml file belongs and that is
pretty much all that can be said.  
   Also, there is more to the RDF Metadata feature when the package
represents an ODF 1.2 document as specified in ODF 1.2 Part 1.  So there is
another level of the feature that is provided in Part 1 and not Part 3 for
ODF 1.2 documents.

This is a little long, but I think it covers the degrees to which some
things are exclusively part of the package models and a spectrum of others
that are less so.


 - Dennis



-----Original Message-----
From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
http://lists.oasis-open.org/archives/oic/200911/msg00040.html
Sent: Monday, November 30, 2009 10:13
To: dennis.hamilton@acm.org
Cc: oic@lists.oasis-open.org
Subject: Re: [oic] odf 1.2 part 3, packages, features

Hi,

Dennis E. Hamilton wrote:
http://lists.oasis-open.org/archives/oic/200911/msg00039.html
> PS: I am a little nervous about relying on the ODF 1.2 Part 3 Public
Review
> Draft in this way, although I think the granularity is about right.  One
> major granularity issue has to do with what is solely and entirely a
feature
> of packages and what is a feature corresponding to an application of
package
> for the specific case of carrying ODF 1.2 document instances.  For
example,
> as far as I can tell, the manifest.xml and the manifest.rdf "manifest"
file
> are quite different beasts in this regard: packaging has no dependency on
> the second and depends intimately on the first.
>   
As I am not sure if I understand you here correctly, do you 
differentiate between a part 1 and part 3 feature or to a feature that 
is new to ODF 1.2?

In any case let me restate the part 3 spec from the bird perspective
a) the manifest.xml is the 'content table' for files/streams within the 
ODF package
b) the manifest.rdf is the 'content table' for RDF metadata within each 
ODF document within the ODF package

The manifest.rdf is 'drawn down' from ODF schema (part 1) to the ODF 
Package layer (part 3), as the ability to attach RDF metadata to 
identifiable XML elements (those with the xml:id attribute),should be a 
shareable feature among all ODF Packages.

Did this help or what exactly did you mean with an ODF 1.2 document 
instance?

[ ... ]