Uploaded image for project: 'OASIS Open Document Format for Office Applications (OpenDocument) TC'
  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OFFICE-2685

ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2 CD 05
    • Fix Version/s: ODF 1.2 CD 06
    • Labels:
      None
    • 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.

    • Proposal:
      Hide

      1. Add [RFC3987] to the Normative References.

      2. Define IRI and relative IRI in some way (a terminology/nomenclature entry would be helpful), with reference to the applicable definitions in [RFC3987] and/or in a specific portion of Part 3, such as section 2.7.

      3. Specify when and how IRI-%-encoding kicks in for URI path segments that are within the package and for URI references that end in the package.

      4. Be careful about speaking of IRIs vs IRI-encoding in URIs and URIs generally.

      5. Make sure we have accounted for normative provisions of [RFC3986] and [RFC3987], of the anyURI datatype, and of whatever it is we say manifest:full-path is and what its relationship to the name recorded for a file as a data unit of the Zip archive.

      Show
      1. Add [RFC3987] to the Normative References. 2. Define IRI and relative IRI in some way (a terminology/nomenclature entry would be helpful), with reference to the applicable definitions in [RFC3987] and/or in a specific portion of Part 3, such as section 2.7. 3. Specify when and how IRI-%-encoding kicks in for URI path segments that are within the package and for URI references that end in the package. 4. Be careful about speaking of IRIs vs IRI-encoding in URIs and URIs generally. 5. Make sure we have accounted for normative provisions of [RFC3986] and [RFC3987] , of the anyURI datatype, and of whatever it is we say manifest:full-path is and what its relationship to the name recorded for a file as a data unit of the Zip archive.
    • Resolution:
      Hide

      Change description of 3.7 Usage of IRIs Within Packages to:

      Within the files contained in a package, relative IRIs as defined by [RFC3987] may be used to reference other files within the same package.
      OpenDocument Package Consumers shall resolve relative IRIs that occur within a file of a package as follows:
      1. The file entry path is the file name of the file within the Zip file which contains the relative IRI, including its relative path.
      2. The package base IRI is the base IRI which would be established for the package itself as defined in §5.1 of [RFC3986].
      3. If the relative IRI does not match the rule for "relative-ref" defined in §4.2 of [RFC3986] or if the relative IRI does start with a "/" character (U+002F, SOLIDUS) then it is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
      4. Otherwise the relative IRI is copied into a relative IRI buffer and the file entry path is copied into a file entry path buffer.
      5. If the relative IRI buffer starts with the character sequence "./" (U+002E, FULL STOP, followed by U+002F, SOLIDUS) then that character sequence it removed from the buffer. Continue with step 5.
      6. If the relative IRI buffer starts with the character sequence "../" (U+002E, FULL STOP, followed by U+002E, FULL STOP, followed by U+002F, SOLIDUS) and

      • if the file entry path buffer contains only a file name but no relative path, then the "../" is removed from the relative IRI buffer. The content of the relative IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
      • if the file entry path buffer contains at least one relative path component, the first relative path component up to and including the first "/" character (U+002F, SOLIDUS) is removed. Continue with step 5.
        7. If the relative IRI buffer contains one or more "#" (U+0023, NUMBER SIGN) characters, the first "#" character is removed from the relative IRI buffer. The characters following the "#" character are copied into a fragment identifier buffer and are then also removed from the relative IRI buffer.
        8. The content of the relative IRI buffer is interpreted as a file name within the package, that is, as the name of a file including its relative path within the Zip file.
        9. If a fragment buffer has been created and is not empty, its content may be resolved as fragment identifier, as defined by §3.5 of [RFC3986].

      Note: Files whose relative path starts with "META-INF/" are considered to be part of the OpenDocument package rather than of the content stored within the package. Therefore, different rules regarding the resolution of relative IRIs may apply. In particular the base URI for the resolution of relative IRIs may be the package base IRI rather than the file entry base IRI.

      Show
      Change description of 3.7 Usage of IRIs Within Packages to: Within the files contained in a package, relative IRIs as defined by [RFC3987] may be used to reference other files within the same package. OpenDocument Package Consumers shall resolve relative IRIs that occur within a file of a package as follows: 1. The file entry path is the file name of the file within the Zip file which contains the relative IRI, including its relative path. 2. The package base IRI is the base IRI which would be established for the package itself as defined in §5.1 of [RFC3986] . 3. If the relative IRI does not match the rule for "relative-ref" defined in §4.2 of [RFC3986] or if the relative IRI does start with a "/" character (U+002F, SOLIDUS) then it is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI. 4. Otherwise the relative IRI is copied into a relative IRI buffer and the file entry path is copied into a file entry path buffer. 5. If the relative IRI buffer starts with the character sequence "./" (U+002E, FULL STOP, followed by U+002F, SOLIDUS) then that character sequence it removed from the buffer. Continue with step 5. 6. If the relative IRI buffer starts with the character sequence "../" (U+002E, FULL STOP, followed by U+002E, FULL STOP, followed by U+002F, SOLIDUS) and if the file entry path buffer contains only a file name but no relative path, then the "../" is removed from the relative IRI buffer. The content of the relative IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI. if the file entry path buffer contains at least one relative path component, the first relative path component up to and including the first "/" character (U+002F, SOLIDUS) is removed. Continue with step 5. 7. If the relative IRI buffer contains one or more "#" (U+0023, NUMBER SIGN) characters, the first "#" character is removed from the relative IRI buffer. The characters following the "#" character are copied into a fragment identifier buffer and are then also removed from the relative IRI buffer. 8. The content of the relative IRI buffer is interpreted as a file name within the package, that is, as the name of a file including its relative path within the Zip file. 9. If a fragment buffer has been created and is not empty, its content may be resolved as fragment identifier, as defined by §3.5 of [RFC3986] . Note: Files whose relative path starts with "META-INF/" are considered to be part of the OpenDocument package rather than of the content stored within the package. Therefore, different rules regarding the resolution of relative IRIs may apply. In particular the base URI for the resolution of relative IRIs may be the package base IRI rather than the file entry base IRI.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Patrick Patrick Durusau
              Reporter:
              orcmid Dennis Hamilton (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: