[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=20643#action_20643 ]
Dennis Hamilton commented on OFFICE-2685:
-----------------------------------------
Michael, I agree that this kind of review is appropriate, as I confirmed on the call today.
I think that one problem about not having to reconcile against a base at all is a problem because there are places in the semantics for anyURI and other uses where it insists that it be possible for there be a full URI created (and this applies to IRIs as well). It seems to be part of the definition of what it means to claim that something is a URI reference.
Clearly, the treatment of character sets and the need for encoding is under our control when a reference requires matching of segments in the manifest:full-path (and the Zip file name).
I believe there is an argument for IRI encoding in this case simply to ensure maximum interoperability and ensure that the character repertoire required is one that can be safely represented in Zip file names.
What I like about this is that any other file-system or location-specific considerations with regard to how IRI encoding is handled in extraction and import of Zip files (or the entire package) is left to the particular implementation and the platform and libraries on which it relies. A producer can safely produce IRI-encoded Zip file names and manifest:ful-path values and a consumer can simply handle them without any consideration of the complexities of import and export into other structures of any kind. I also believe that the current use of monocase in segments with limited use of special characters that do not require %-encoding is the safest approach of all. I think we should recommend that ("should") even though we might not feel able to require it.
Side note: These considerations are also helpful when a relative IRI is used to refer to a companion file (even another package) that is located nearby, as is the case for multiple ODF documents under a master document. How the full IRI is then mapped to the file system character set and naming rules is, of course, specific to the platform integration of an implementation. But the full IRI itself can be completely unambiguous and portable (so long as the other files can be transported along with the referencing document in a way that preserves the IRI resolution in the new context).
> 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]