[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 LONG POSTSCRIPT: 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 "sub/document/..." 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 "./" Regards, Svante Am 30.06.2010 20:42, schrieb Dennis E. Hamilton: I am sure I am missing something in your question. Look at the manifest.xml files in the ODF specifications. None of them have manifest:full-path values that begin with "." and the only one beginning with "/" is the artificial one for the overall document that the package represents. (Zip directory entries are forbidden to have names beginning with "/".) I notice there is a tendency in some OpenDocument Producers to create subdocuments for every possible full-path leading segment ending in "/" but there is no requirement for that in the Package specification, especially with manifest:media-type="". In fact, I believe such manifest:media-type values do not conform to the MIME Type RFC and such <manifest:file-entry> elements are better created with omission of the manifest:media-type attribute. - 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 the package root ODF 1.2 part 3 4.8.4 manifest:full-path "The attribute value "/" denotes a manifest entry for the package itself." Does not all path of the manifest have to be a relative paths and therefore the path have to be "./" for the root document and the package itself? [ ... ] --------------------------------------------------------------------- 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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]