OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] Question regarding ODF 1.2 CD05 part 3 - path of the package root

I was questioning manifest:media-type="", not manifest:full-path="".

(Although I don't think either is permitted by anything in ODF 1.2 Part 3.)

I have been struggling with that statement in ODF 1.2 CD05 Part 3 section
3.7.  As far as I can tell, it does not say anything about the
manifest:full-path value associated with the file.  In fact, the term "file
entry path" is apparently being defined there and is only ever used in the
third list entry of the same list.  It could have been stated more simply in
terms of the Zip filename (or matching manifest:full-path value) for the XML
document that contains the relative IRI reference.

As far as I can tell, the reference to relative path in the Zip is simply
strange.  Although the "relative path" term is also used in the current
description for manifest:full-path (4.8.4), this is never explained or
defined except to say that the manifest:full-path value is the same as the
"filename" in the Zip central directory entry for the "file or directory
within the package."  However, not every manifest:full-path value
corresponds to a "filename" in the Zip central directory (or in any of the
other entries in the Zip).  "/", "Thumbnails/", "META-INF/", etc., do not.
There are no "paths" in the Zip file structure itself, and if we want to
have such a concept applicable to packages, we need to do a better job of
specifying what it is.

I for one believe we can define how this is meant to work without speaking
of relative paths in the package structure at all.  We can speak of relative
IRIs and resolve them in the package structure without suggesting anything
about relativity of manifest:full-path values.

 - Dennis


It seems as if I have fretted over this for as long as I have been on the
ODF TC and before.  Here is how it looks to me at the moment:

I don't think we need to speak of manifest:full-path values as relative
anything.  We can do the job without such extraneous terms.  We only need to
establish something like

  1. Every manifest:full-path value for a subdocument ends in "/" and does
not start with "/", as in "sub/document/" (where there may but need not be
intermediate "/" in the full-path value).  Every file and inner subdocument
that is part of that subdocument has a manifest:full-path value of form

  2. A manifest:full-path value cannot begin with "/" except for the special
full-path value "/" representing the document representation that is
comprised of all files in the OpenDocument Package.

  3. Consecutive "/" are not allowed in manifest:full-path values nor in Zip
central directory filenames. 

  4. Every manifest:full-path value that does not end in "/" corresponds to
a file of the package and is the same as the "filename" in the Zip central
directory.  No "filename" in the Zip central directory ends in "/".  There
shall be no two <manifest:file-entry> elements for which the
manifest:full-path values are the same or for which the only difference is
"/" on the end of one of them.

  5. Because the character-set encoding of the filename in the Zip central
directory might not be a Unicode encoding, there may need to be some IRI
encoding in the manifest:full-path value and/or the Zip central directory
filename.  This is also something that needs to be defined better for IRIs
to be usable, since PKWare tells us that directory filenames are by
convention encoded using a single-byte code page.  They should probably be
considered to carry only the ASCII encoding of the 95 "printable" Basic
Latin characters and limited further to line up with rules for URLs and the
URL coding of anything else. That way, we are assured that the files can
actually be reached with relative IRIs.  That is, we don't want full-paths
and Zip filenames that can't be reached via (relative) IRI because the URL
syntax doesn't permit it.

  6. Note that a "/" in the middle of a manifest:full-path value, such as
"leading-part/trailing-part" does not require there to be a defined
subdocument with manifest:full-path="leading-part/" unless there is need to
associate a meaningful manifest:media-type with "leading-part/" or be able
to refer to the subdocument as a whole (say, to introduce a
"leading-part/manifest.rdf" file).  ODF 1.0/1.1/IS 26300 have said as much
and there is no reason to presume that it is otherwise for ODF 1.2.

  7. It is convenient for packages to be created in a way that the files of
the package can be extracted into and imported from hierarchical file
systems by interpreting the "/" in the Zip central directory filename as a
separator of path segments naming directory levels in some hierarchical
sub-structure of a file system.  No such correspondence is established for
OpenDocument Packages.  There is no assurance that the Zip central directory
names for the files in the ODF package will be valid path-segment names and
file names for any file system whatsoever.  (I.e., case-sensitivity,
character-repertoire, name-structure, and path-segment and path-length
limitations and variations are not considered.) 

There is a fair amount of clean-up that we can provide to have this aspect
of OpenDocument Package specified more precisely.

-----Original Message-----
From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
Sent: Wednesday, June 30, 2010 12:33
To: office@lists.oasis-open.org; dennis.hamilton@acm.org
Subject: Re: [office] Question regarding ODF 1.2 CD05 part 3 - path of the
package root

Hi Dennis,

It seems inconsistent that all ODF documents from the package are specified
in the manifest.xml using manifest:full-path via an relative path/URL , only
the root document got an absolute path. 

In 3.7 "Usage of IRIs Within Packages" we write 

OpenDocument Package Consumers shall resolve relative IRIs that occur within
a file of a package as follows: 

*	The file entry path is the file name of the file within the Zip file
which contains the relative IRI, including its relative path.

And you are right, the empty String seems as valid as "./"


Am 30.06.2010 20:42, schrieb Dennis E. Hamilton: 

	I am sure I am missing something in your question.  Look at the
	files in the ODF specifications.  None of them have
	values that begin with "." and the only one beginning with "/" is
	artificial one for the overall document that the package represents.
	directory entries are forbidden to have names beginning with "/".)
	I notice there is a tendency in some OpenDocument Producers to
	subdocuments for every possible full-path leading segment ending in
"/" but
	there is no requirement for that in the Package specification,
	with manifest:media-type="". In fact, I believe such
	values do not conform to the MIME Type RFC and such
	elements are better created with omission of the manifest:media-type
	 - Dennis
	-----Original Message-----
	From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
	Sent: Wednesday, June 30, 2010 11:08
	To: 'Svante.Schubert@Sun.COM'; 'office@lists.oasis-open.org'
	Subject: RE: [office] Question regarding ODF 1.2 CD05 part 3 - path
of the
	package root
	[ ... ]
	-----Original Message-----
	From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
	Sent: Wednesday, June 30, 2010 09:16
	To: office@lists.oasis-open.org
	Subject: [office] Question regarding ODF 1.2 CD05 part 3 - path of
	package root
	ODF 1.2 part 3 
	4.8.4 manifest:full-path 
	"The attribute value "/" denotes a manifest entry for the package
	Does not all path of the manifest have to be a relative paths and
	the path have to be "./" for the root document and the package
	[ ... ]
	To unsubscribe from this mail list, you must leave the OASIS TC that
	generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]