[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=20667#action_20667 ]
Dennis Hamilton commented on OFFICE-2685:
-----------------------------------------
I want to amplify this principle a little:
'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. "
along with this, I also think that we should do IRI-coding in IRI references without concern for whether the target resource is in the package or not. The 6-point proposal fits with that.
But here is why it is important to have every segment in a Zip file name be such that it can be matched directly with the first segment of a path-noscheme IRI reference.
A. Consider an ODF Package that has the following package files (by their manifest:full-path values):
1. a.xml
2. 1/b.xml
3. 1/1.1/c.xml
4. 2/2.1/d.xml
5. 2/2.1/e.xml
6. 2/2.2/f.xml
7. 2/g.xml
B. a.xml can refer to the any of the other parts (2-6) by URI references that are exactly the same as their manifest:full-path values.
C. To refer to a.xml from the other package files, 1/b.xml can do so with the URI ../a.xml. The other files (3-6) can do so with the URI ../../a.xml
D. To refer to the document as a whole, one would expect that a.xml can do that with URI ./ (though this is ambiguous in some of the rules, even though there is a suitable manifest entry for that), 1/b.xml could do it with ../, and the others with ../../
[This is valuable to be able to do, and we need to come back to what would enable this. The way I just illustrated this case, if a.xml used the URI reference "../" it would be to the location of the package in whatever place it is a resource and since we don't know the name of the package in that context, we can't refer back "in" via that path. Hold that thought.]
E. 2/2/1/e.xml can refer to 2/2/2f.xml via IRI reference "../2.2/f.xml"
F. 2/2.1/d.xml can refer to 2/2.1/e.xml via IRI reference "e.xml" and 2/2.1/e.xml refers back with IRI reference "d.xml".
G. 2/g.xml can use IRI references "2.1/d.xml" and "2.1/e.xml" to refer to those cousins.
H. 1/b.xml can use IRI reference "1.1/c.xml" to refer to that cousin.
THE POINT: There is not any segment of a manifest:full-path value that isn't potentially the leading segment of a relative IRI (path-noscheme) reference that resolves to that particular package file. So using the same rule for all segments is an important simplifier permitting simple usage.
I. In addition, if it happens that "1/" identfies a subdocument, and that "2/2.1/" identifies another subdocument, those are also the forms of IRI references to those subdocuments from a.xml. 1/b.xml would refer to "2/2.1/" via IRI reference "../2/2.1/" and 2/g.xml would refer to "2/2.1/" via IRI reference "2.1/"
> 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]