[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2685) NEEDS-DISCUSSION:ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined
[ http://tools.oasis-open.org/issues/browse/OFFICE-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20629#action_20629 ]
Dennis Hamilton commented on OFFICE-2685:
-----------------------------------------
Patrick and I have had an exchange about the lack of specific, detailed proposal on this issue on the list at
<http://lists.oasis-open.org/archives/office/201008/msg00512.html>
and <http://lists.oasis-open.org/archives/office/201008/msg00514.html>.
I opened this issue and assigned it to myself with the expectation that I have analyzed this situtaion enough to prepare a detailed proposal (probably as change-marked text rather than a plaintext narrative here).
But first I want to have some degree of concurrence on direction and the various issues to be balanced. This analysis, as rambling as it may be, is the evolution of my thinking on this issue. Also, I would like my work and the supporting analysis of RFCs to be checked. I don't want to make something up that sounds ok or not ok and that is it.
Here is the foundation that I propose::
1. For ODF packages, the file names in Zip local file headers and in the Zip central directory file headers for the same file data shall exactly agree with the manifest:full-path entry for the package file that file data carries (on possibly compressed and encrypted form).
2. The character repertoire and syntax of the manifest:full-path entry and the Zip file name shall be such that they can always be be referenced by IRI-coding of URI references of path-noscheme form expressed in any other package file being itself so referenceable.
3. To assure satisfaction of (2), the file name in Zip local file headers shall be carried in single-byte codes corresponding to the ASCII character set encoding (matching the Unicode Basic Latin character code point values in their single-byte values). The syntax shall match that of the path-noscheme URI syntax in which only unreserved characters and and pct-encoded patterns are permitted. In addition, there shall be no empty segment nor shall there be segments of form "." and ".." Consequently, no Zip file name nor its corresponding manifest:full-path attribute value begins with or ends with the segment separator, "/". [Note, this does not prevent the appearance of such segments in relative URI references, it simply forbids them in the actual Zip file names and in manifest:full-path values.]
4. The manifest:full-path value for an identified subdocument of the ODF package shall have the same form as a file name (3), but it shall always end with an additional, final "/". There shall be no manifest:full-path value (nor Zip file name) that is the same as a subdocument manifest:full-path value but without the added "/". Those files and subdocuments whose manifest:full-path values have a leading substring that exactly matches the manifest:full-path value for a subdocument are components of that subdocument.
5. The representation of "%", "/" and all other Unicode characters that are not unreserved (such as SP) shall be by percent-encoding of single byte values in accordance with IRI encoding conventions. Unreserved charactes shall not be percent-encoded. Only capital letters shall be used in the two hexadecimal character-codes that appear in a percent-encoding.
6. Package producers shall not introduce two manifest:full-path values that differ only in the case of alphabetic letters in their character repertoire. All comparisons for matching manifest:full-path values in resolving references shall be case sensitive,
The current scheme for resolving URI references to package files and subdocuments holds pretty much.
We can now sharpen the notion of package file and subdocument and also define IRI reference to consist of a path-noscheme relative URI reference subject to the IRI encoding convention. (We can also include IRI references of other forms, but only the path-noscheme ones are of interest for resolving to package files and subdocuments of the same package as the source of the reference.
> NEEDS-DISCUSSION: ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined
> -------------------------------------------------------------------------------------------
>
> Key: OFFICE-2685
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-2685
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: Packaging, Part 3 (Packages), Schema and Datatypes
> Affects Versions: ODF 1.2 CD 05
> Environment: This applies to all versions of OpenDocument-v1.2-part3-cd1 through -rev04. It also impacts ODF 1.2 Part 1 and ODF 1.2 Part 2 wherever anyURI or equivalent datatype is used in a relative reference.
> Reporter: Dennis Hamilton
> Assignee: Dennis Hamilton
> Fix For: ODF 1.2 CD 06
>
>
> The terms "IRI" and "relative IRI" are used throughout ODF 1.2 Part 3.
> 1. There are no definitions offered for these terms.
> 2. There are no references (normative or otherwise) to sources on this terminology (although [RFC3987] would appear to be a good choice).
> 3. The manner in which IRIs are to be mapped to URIs in those places where resolution involves URI segments within a package is not defined, nor is the relationship to IRI-encoding in URIs accounted for in the definition of (a) the manifest:full-path attribute or (b) the format for names of files in the ZIP data units that carry files within the ZIP archive. In particular, there should be attention to [RFC3987] sections 6.2-6.4, not merely 6.5.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]