Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Working Draft
    • Component/s: ODF11-InteropProfile
    • Labels:
      None
    • Proposal:
      Hide
      1) Write an "interop note" what the recommended way of referring to sub-packages is
      2) Forward it to the ODF TC, to make sure that subpackages will be more clearly specified in ODF 1.2
      Show
      1) Write an "interop note" what the recommended way of referring to sub-packages is 2) Forward it to the ODF TC, to make sure that subpackages will be more clearly specified in ODF 1.2

      Description

      From the tests performed on the The Hague plugtest wiki.

      Testing spreadsheets with an embedded chart revealed that some implementations use
      <draw:object xlink:href="./Object 1"...

      While other(s) use:

      <draw:object xlink:href="Object 1/"...

      (The latter seems to be better)

      ODF 1.1 mentions sub packages in 9.3.3 Objects (Object Data), but the wording can be improved
      "For objects that have an XML representation, the link references the sub package of the object. The object is contained within this sub page exactly as it would as it is a document of its own."

      And perhaps 17.5, Usage of IRIs Within Packages

      "A relative-path reference (as described in §6.5 of [RFC3987]) that occurs in a file that is contained in a package has to be resolved exactly as it would be resolved if the whole package gets unzipped into a directory at its current location. The base IRI for resolving relative-path references is the one that has to be used to retrieve the (unzipped) file that contains the relative-path reference."

        Activity

        Hide
        Dennis Hamilton added a comment -
        Side note: I am not clear how this issue advances to some kind of recommendation, so I am speculating about that in this comment.

        The deliverable is apparently an ODF Interoperability Profile which is a specification from this TC. Resolution of this issue would appear to be (1) agreement on the problem (2) exploration of a suitable agreement for reconciling implementations, and (3) reflection of the agreement in the profile.

        TECHNICAL CONSIDERATIONS:

        There is an interaction between 17.5 and the way that a subdocument is reflected in the manifest for the main document (in 17.7). We need to consider how the manifest is aligned in any proposed agreement.. A subdocument is presumably represented with a manifest:full-path value and a manifest:media-type value in a <manifest:file-entry> element. For individual content items, the manifest:full-path value and the name of the Zip content item are presumably identical. Any content items that are the components of the subdocument presumably have the subdocument manifest:full-path value as prefixes on their manifest:full-path values and Zip content-item names. Some, not necessarily all, of these will have their own corresponding <manifest:file-entry> elements.

        Since there are no folders in Zip and no content items for folders, as such, the <manifest:file-entry> for a subdocument has no corresponding Zip content item. The one example in the ODF specification (and only as an example) has manifest:full-path="/" with manifest:media-type being the MIME type of the package itself.

        So for starters, there is the question of what is the relationship between full-path values and content-item names, and what is that relationship when the full-path is for a conceptual folder that has no corresponding content-item, but there may be many content-items (or none) that have structurally-related names (and/or full-path attribute names).

        Along with that, there is also the reconciliation of how IRIs that access other components of the same Package are to work. This is where 17.5 comes in.

        RECONCILING THIS

        I suspect that there is a consistent way to deal with this and whatever it is, it has to work for whatever OO.o did in 2.x and does in 3.x.

        So we need to make some documents, using OO.o, that demonstrate how subdocuments and other use of folders having manifest entries are identified via manifest:full-path values and then how IRIs are created that refer to those.

        What is discovered in that experiment should then allow us to figure out a scenario for exploring how other implementations do this (using equivalent test-document creation procedures).

        We can then also see how other documents accept ones produced by the other implementations.

        Then it requires some sort of alignment among the affected parties on how they can adjust implementations and how they can move forward in dealing with deviating legacy documents of whatever their origins are.

        I suspect that a profile on this matter depends on what that alignment is.

        This seems like something worthwhile for taking to the Orvieto-timeframe event, wherever it is. We might also know, by then, what is proposed to be done about this matter, if anything, in ODF 1.2.

        Finally, is there already something like a gentlemen's agreement out of the recent plugfest on what the answer is to the question of what the IRI is expected to look like (i.e., where does the "/" go when refering to a subpackage? To a subpackage of a subpackage?

        [PS: There are a number of open issues about subpackages. For example: (1) it needs to be clear that the subpackage cannot have any mimetype, META-INF/manifest.xml, nor Thumbnails/thumbnail.png content items; (2) It is meaningless for there to be encryption information in the <manifest:file-item> for a subdocument; (3) there are content-items having "/" within their names that have no corresponding <manifest:file-entry> element, and that are nonetheless accessible via IRIs from XML documents within the package (e.g., "images/mumble.jpg"); and (4) there is no specified agreement on the admissible character set, case sensitivity, and structural requirements for content-item names and the corresponding manifest:full-path values, if any. One could easily see this problem of the path references to subdocuments as just one of a variety of alignments to be achieved around the interoperable production and consumption of ODF documents in packages.]

        Show
        Dennis Hamilton added a comment - Side note: I am not clear how this issue advances to some kind of recommendation, so I am speculating about that in this comment. The deliverable is apparently an ODF Interoperability Profile which is a specification from this TC. Resolution of this issue would appear to be (1) agreement on the problem (2) exploration of a suitable agreement for reconciling implementations, and (3) reflection of the agreement in the profile. TECHNICAL CONSIDERATIONS: There is an interaction between 17.5 and the way that a subdocument is reflected in the manifest for the main document (in 17.7). We need to consider how the manifest is aligned in any proposed agreement.. A subdocument is presumably represented with a manifest:full-path value and a manifest:media-type value in a <manifest:file-entry> element. For individual content items, the manifest:full-path value and the name of the Zip content item are presumably identical. Any content items that are the components of the subdocument presumably have the subdocument manifest:full-path value as prefixes on their manifest:full-path values and Zip content-item names. Some, not necessarily all, of these will have their own corresponding <manifest:file-entry> elements. Since there are no folders in Zip and no content items for folders, as such, the <manifest:file-entry> for a subdocument has no corresponding Zip content item. The one example in the ODF specification (and only as an example) has manifest:full-path="/" with manifest:media-type being the MIME type of the package itself. So for starters, there is the question of what is the relationship between full-path values and content-item names, and what is that relationship when the full-path is for a conceptual folder that has no corresponding content-item, but there may be many content-items (or none) that have structurally-related names (and/or full-path attribute names). Along with that, there is also the reconciliation of how IRIs that access other components of the same Package are to work. This is where 17.5 comes in. RECONCILING THIS I suspect that there is a consistent way to deal with this and whatever it is, it has to work for whatever OO.o did in 2.x and does in 3.x. So we need to make some documents, using OO.o, that demonstrate how subdocuments and other use of folders having manifest entries are identified via manifest:full-path values and then how IRIs are created that refer to those. What is discovered in that experiment should then allow us to figure out a scenario for exploring how other implementations do this (using equivalent test-document creation procedures). We can then also see how other documents accept ones produced by the other implementations. Then it requires some sort of alignment among the affected parties on how they can adjust implementations and how they can move forward in dealing with deviating legacy documents of whatever their origins are. I suspect that a profile on this matter depends on what that alignment is. This seems like something worthwhile for taking to the Orvieto-timeframe event, wherever it is. We might also know, by then, what is proposed to be done about this matter, if anything, in ODF 1.2. Finally, is there already something like a gentlemen's agreement out of the recent plugfest on what the answer is to the question of what the IRI is expected to look like (i.e., where does the "/" go when refering to a subpackage? To a subpackage of a subpackage? [PS: There are a number of open issues about subpackages. For example: (1) it needs to be clear that the subpackage cannot have any mimetype, META-INF/manifest.xml, nor Thumbnails/thumbnail.png content items; (2) It is meaningless for there to be encryption information in the <manifest:file-item> for a subdocument; (3) there are content-items having "/" within their names that have no corresponding <manifest:file-entry> element, and that are nonetheless accessible via IRIs from XML documents within the package (e.g., "images/mumble.jpg"); and (4) there is no specified agreement on the admissible character set, case sensitivity, and structural requirements for content-item names and the corresponding manifest:full-path values, if any. One could easily see this problem of the path references to subdocuments as just one of a variety of alignments to be achieved around the interoperable production and consumption of ODF documents in packages.]
        Hide
        Dennis Hamilton added a comment - - edited
        The use of "." and ".." is part of the URI/IRI specification. So having a leading "./" (or leading "././" or ...) is a well-defined case, even when omission of the "./" would not change how the reference is resolved.

        The requirement for the trailing "/" appears to be a different matter (although HTTP [and WebDAV] specifications appear to have a position about it and it is useful to be consistent). It will be very interesting to see what manifest:full-path values have for subdocuments in the different implementations and how that squares with how the IRIs are written. This might or might not provide additional insight on the issue and its resolution.
        Show
        Dennis Hamilton added a comment - - edited The use of "." and ".." is part of the URI/IRI specification. So having a leading "./" (or leading "././" or ...) is a well-defined case, even when omission of the "./" would not change how the reference is resolved. The requirement for the trailing "/" appears to be a different matter (although HTTP [and WebDAV] specifications appear to have a position about it and it is useful to be consistent). It will be very interesting to see what manifest:full-path values have for subdocuments in the different implementations and how that squares with how the IRIs are written. This might or might not provide additional insight on the issue and its resolution.
        Hide
        Dennis Hamilton added a comment -
        As further context, I should point out that section 17.5 of the ODF 1.0/IS 26300/ODF 1.1 specifications is the subject of defect reports from individuals and ISO/IEC JTC1 SC34. In ODF 1.0 Errata 01, this issue was deferred to future resolution. (One problem is that ODF 1.0 has different language than IS 26300 and ODF 1.1 so a single erratum can't work for all.) Reconciliation of 17.5 has come up again (since it has been repeated in a later SC34 defect report) and I expect there will be further clean-up for ODF 1.2, beyond what may be necessary to resolve the specific defect reports that there are.

        Secondly, since this is such a snake to deal with, I wonder if UOF harmonization collides with this. That is, does UOF use a package scheme, is it enough like that of ODF to be near-interoperable, and what does the UOF specification say about packaging? Are there any useful links or other resources with regard to UOF packaging?

        [I thought about making a separate issue about this, but I think it might as well just tag along with this particular nest of snakes.]
        Show
        Dennis Hamilton added a comment - As further context, I should point out that section 17.5 of the ODF 1.0/IS 26300/ODF 1.1 specifications is the subject of defect reports from individuals and ISO/IEC JTC1 SC34. In ODF 1.0 Errata 01, this issue was deferred to future resolution. (One problem is that ODF 1.0 has different language than IS 26300 and ODF 1.1 so a single erratum can't work for all.) Reconciliation of 17.5 has come up again (since it has been repeated in a later SC34 defect report) and I expect there will be further clean-up for ODF 1.2, beyond what may be necessary to resolve the specific defect reports that there are. Secondly, since this is such a snake to deal with, I wonder if UOF harmonization collides with this. That is, does UOF use a package scheme, is it enough like that of ODF to be near-interoperable, and what does the UOF specification say about packaging? Are there any useful links or other resources with regard to UOF packaging? [I thought about making a separate issue about this, but I think it might as well just tag along with this particular nest of snakes.]
        Hide
        Peter Junge added a comment -
        Dennis,
        usually you can find some material on the website of the UOF TC:
        http://www.uof.org.cn/ (seems to have technical problems at the moment)
        It includes schemas and an English version (PDF, ugly formatted) of the specification. Unfortunately, this is not a translation of the final spec, but of an earlier draft. English documentation is not officially maintained by the UOF TC AFAIK.
        A comparison of ODF and UOF compiled by IBM and Peking university, you can find at:
        http://sourceforge.net/project/downloading.php?group_id=182680&use_mirror=osdn&filename=ODF-UOF-comparison-doc.zip&20832893
        AFAIK, the English version of the UOF draft is also a result of this studies. Maybe Ming Fei Jia can help you to get connected with the authors.
        Show
        Peter Junge added a comment - Dennis, usually you can find some material on the website of the UOF TC: http://www.uof.org.cn/ (seems to have technical problems at the moment) It includes schemas and an English version (PDF, ugly formatted) of the specification. Unfortunately, this is not a translation of the final spec, but of an earlier draft. English documentation is not officially maintained by the UOF TC AFAIK. A comparison of ODF and UOF compiled by IBM and Peking university, you can find at: http://sourceforge.net/project/downloading.php?group_id=182680&use_mirror=osdn&filename=ODF-UOF-comparison-doc.zip&20832893 AFAIK, the English version of the UOF draft is also a result of this studies. Maybe Ming Fei Jia can help you to get connected with the authors.
        Hide
        Bart Hanssens added a comment -
        added in wd
        Show
        Bart Hanssens added a comment - added in wd
        Hide
        Svante Schubert added a comment -
        Regarding different usage of relative URI in ODF:
        ========================================
        I believe we all agree that we can normalice normalize relative URLs on document XML level in ODF 1.2

        On document level ODF implementations write out different URLs for the same referenced object:
        For instnace different @href values might indeed correctly reference to the same object as "./Object 1", "Object 1", "Object 1/", "./Object 1/" (even many more variations as "./Object 1/./././" are possible - if I interpret http://www.apps.ietf.org/rfc/rfc3986.html#sec-3.3 correctly).

        If we would limit our document URL encoding, we would force any File Format Transformation (like XHTML to ODF) to verify the value of attributes containing URLs (e.g. the @href attribute), creating an ODF relative URL subset.

        If the problem is only triggered by ODF XML comparison this URL normalization can be part of the ODF normalization before comparison. Still a best practice advice (the result of a normalization) might be given.

        On the other hand, if we are talking about the Package level, there are different requirements:
        Here the relative paths within manifest's full-path attribute is often usually used by an ODF implementation as unique key for a package file a normalized encoding might be useful and even recommended to prevent a potential harmful "../../../../../.bash". In the end we would remove substring as "/./" "/../" and "//" and prefixes as "./" "../".

        The ZIP Note ODF 1.2 is referencing to
        http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt
        is unfortunately not specifying the term "relative path" any further (not even an RFC is referenced).

        Before moving this issue to the ODF 1.2 TC, I would suggest to ask a comment from PKWARE, why not using normalized paths (and referencing for relatives path http://www.apps.ietf.org/rfc/rfc3987.html#sec-6.5 )

        PS: We might ask as well to refer to ODF aside of OOXML in http://www.pkware.com/support/application-note-archives

        Regarding subdocument in ODF:
        ===========================

        Every directory in the manifest with a mimetype is a document within the package. For instance OpenOffice creates directory with configuration files, which have a MIME type and are therefore Package documents.
        This is indeed a matter we should raise in the ODF TC. Especially as I did a proposal about two years ago in the context of metadata that tried to explain the entity of a document on Package layer level:

        See http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_Metadata_according_Embedded_Document_Scenario?highlight=(CategoryApprovedProposal\b)|(CategoryCategory\b)#RequestedchangestotheODFStandard

        Svante
        Show
        Svante Schubert added a comment - Regarding different usage of relative URI in ODF: ======================================== I believe we all agree that we can normalice normalize relative URLs on document XML level in ODF 1.2 On document level ODF implementations write out different URLs for the same referenced object: For instnace different @href values might indeed correctly reference to the same object as "./Object 1", "Object 1", "Object 1/", "./Object 1/" (even many more variations as "./Object 1/./././" are possible - if I interpret http://www.apps.ietf.org/rfc/rfc3986.html#sec-3.3 correctly). If we would limit our document URL encoding, we would force any File Format Transformation (like XHTML to ODF) to verify the value of attributes containing URLs (e.g. the @href attribute), creating an ODF relative URL subset. If the problem is only triggered by ODF XML comparison this URL normalization can be part of the ODF normalization before comparison. Still a best practice advice (the result of a normalization) might be given. On the other hand, if we are talking about the Package level, there are different requirements: Here the relative paths within manifest's full-path attribute is often usually used by an ODF implementation as unique key for a package file a normalized encoding might be useful and even recommended to prevent a potential harmful "../../../../../.bash". In the end we would remove substring as "/./" "/../" and "//" and prefixes as "./" "../". The ZIP Note ODF 1.2 is referencing to http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt is unfortunately not specifying the term "relative path" any further (not even an RFC is referenced). Before moving this issue to the ODF 1.2 TC, I would suggest to ask a comment from PKWARE, why not using normalized paths (and referencing for relatives path http://www.apps.ietf.org/rfc/rfc3987.html#sec-6.5 ) PS: We might ask as well to refer to ODF aside of OOXML in http://www.pkware.com/support/application-note-archives Regarding subdocument in ODF: =========================== Every directory in the manifest with a mimetype is a document within the package. For instance OpenOffice creates directory with configuration files, which have a MIME type and are therefore Package documents. This is indeed a matter we should raise in the ODF TC. Especially as I did a proposal about two years ago in the context of metadata that tried to explain the entity of a document on Package layer level: See http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_Metadata_according_Embedded_Document_Scenario?highlight=(CategoryApprovedProposal \b)|(CategoryCategory\b)#RequestedchangestotheODFStandard Svante
        Hide
        Dennis Hamilton added a comment -
        Svante, this is an interesting comment, but I have no idea what you mean by normalization here. This is not any normalization that is defined in the URI specification, is it? There is no normalization currently defined in the ODF specification either, is that right?

        Also, there is a complex set of interlocking technical considerations here, and I believe, as I said on today's call, that the ODF TC is the appropriate place to sort this out.

         - Dennis

        A Few Observations:

        The leading ./ is irrelevant in resolution of relative URI references in a package. It is resolved exactly the same as if the ./ is not there, the same as relative no-scheme URI references everywhere. The only reason for having it in a no-scheme relative URI reference is if the segment immediately after the ./ has a colon in it. This is to prevent the URI reference being ambiguously-recognized as one having a scheme name.

        (Aside: Also, there should never be a "./" in a manifest:full-path because it is not a URI reference of any kind, it is a mapping to package files and subdocuments with their mime types, encryption information, etc., and we would not put "./" on the front of names in the Zip directory for any useful purpose.

        (Aside: Since there may be many different relative URIs that reference relative to a full-path segment, it is probably preferable to simply not allow ":" anywhere in manifest:full-path and in the names of files in the Zip directory, so one can reliably create no-scheme relative URIs involving them with no problem.)

        PS: I notice in recent versions of OO.o that there is a manifest entry created for every "directory" whether it is really a subdocument root or not, and a blank MIME type is used for most of them. There is no reason for this in terms of the needs of ODF, and there is no provision in the ODF specification for empty strings as the value of the manifest:media-type attribute.
           In ODF 1.0/1.1 it was stated that a "directory" entry is needed only if there is a subdocument having that full-path as a prefix (i.e., root name) for all files (and interior subdocuments) that it contains. It establishes the subdocument and also establishes the MIME type.

         (The manifest:full-path="/" is a special case, because the leading "/" does not appear on the names of files in the ZIp directory nor does it appear in the front of manifest:full-path entries for those and any subdocuments.).
        Show
        Dennis Hamilton added a comment - Svante, this is an interesting comment, but I have no idea what you mean by normalization here. This is not any normalization that is defined in the URI specification, is it? There is no normalization currently defined in the ODF specification either, is that right? Also, there is a complex set of interlocking technical considerations here, and I believe, as I said on today's call, that the ODF TC is the appropriate place to sort this out.  - Dennis A Few Observations: The leading ./ is irrelevant in resolution of relative URI references in a package. It is resolved exactly the same as if the ./ is not there, the same as relative no-scheme URI references everywhere. The only reason for having it in a no-scheme relative URI reference is if the segment immediately after the ./ has a colon in it. This is to prevent the URI reference being ambiguously-recognized as one having a scheme name. (Aside: Also, there should never be a "./" in a manifest:full-path because it is not a URI reference of any kind, it is a mapping to package files and subdocuments with their mime types, encryption information, etc., and we would not put "./" on the front of names in the Zip directory for any useful purpose. (Aside: Since there may be many different relative URIs that reference relative to a full-path segment, it is probably preferable to simply not allow ":" anywhere in manifest:full-path and in the names of files in the Zip directory, so one can reliably create no-scheme relative URIs involving them with no problem.) PS: I notice in recent versions of OO.o that there is a manifest entry created for every "directory" whether it is really a subdocument root or not, and a blank MIME type is used for most of them. There is no reason for this in terms of the needs of ODF, and there is no provision in the ODF specification for empty strings as the value of the manifest:media-type attribute.    In ODF 1.0/1.1 it was stated that a "directory" entry is needed only if there is a subdocument having that full-path as a prefix (i.e., root name) for all files (and interior subdocuments) that it contains. It establishes the subdocument and also establishes the MIME type.  (The manifest:full-path="/" is a special case, because the leading "/" does not appear on the names of files in the ZIp directory nor does it appear in the front of manifest:full-path entries for those and any subdocuments.).
        Hide
        Dennis Hamilton added a comment -
        I noticed that I can't find this JIRA issue on the OIC JIRA dashboard because it is marked as closed.

        Svante,

        I looked at the use of "relative path" in the [Zip] specification at http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt.

        This is only one occurrence of the term, and it is never defined. (This is an extremely informal document.)

        The use of "relative path" is in the context of whether or not path information is added to a Zip document filename in the Zip directory when a file is moved into the Zip. Those specification authors were not thinking about URLs at all, but about hierarchical file systems. Also, there is no indication of "relative-to-what," although the utilities I use allow me to say how much information from the original location of the files is included in the Zip. The Zip authors were not thinking about producers and consumers of Zip packages that worked with the package directly as a container and not as a means for archiving file-system data.

        Here's the specific mention that I think we are talking about:

        "file name: (Variable)

                  The name of the file, with optional relative path.
                  The path stored should not contain a drive or
                  device letter, or a leading slash. All slashes
                  should be forward slashes '/' as opposed to
                  backwards slashes '\' for compatibility with Amiga
                  and Unix file systems etc. If input came from standard
                  input, there is no file name field."

        The file name field occurs in what is called the local file header (it is a block of data that precedes the data of the file). It is repeated in the file header that is also provided in the "central directory," near the end of the Zip package.

        It appears that the value of manifest:full-path for a package file (not a sub-document) should be an exact match for a file name entry in the Zip directory. There is no Zip filename match for a sub-document manifest:full-path entry. There may be one or more package files that have the subdocument full-path value as the leading part of the Zip file name, however.
        Show
        Dennis Hamilton added a comment - I noticed that I can't find this JIRA issue on the OIC JIRA dashboard because it is marked as closed. Svante, I looked at the use of "relative path" in the [Zip] specification at http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt . This is only one occurrence of the term, and it is never defined. (This is an extremely informal document.) The use of "relative path" is in the context of whether or not path information is added to a Zip document filename in the Zip directory when a file is moved into the Zip. Those specification authors were not thinking about URLs at all, but about hierarchical file systems. Also, there is no indication of "relative-to-what," although the utilities I use allow me to say how much information from the original location of the files is included in the Zip. The Zip authors were not thinking about producers and consumers of Zip packages that worked with the package directly as a container and not as a means for archiving file-system data. Here's the specific mention that I think we are talking about: "file name: (Variable)           The name of the file, with optional relative path.           The path stored should not contain a drive or           device letter, or a leading slash. All slashes           should be forward slashes '/' as opposed to           backwards slashes '\' for compatibility with Amiga           and Unix file systems etc. If input came from standard           input, there is no file name field." The file name field occurs in what is called the local file header (it is a block of data that precedes the data of the file). It is repeated in the file header that is also provided in the "central directory," near the end of the Zip package. It appears that the value of manifest:full-path for a package file (not a sub-document) should be an exact match for a file name entry in the Zip directory. There is no Zip filename match for a sub-document manifest:full-path entry. There may be one or more package files that have the subdocument full-path value as the leading part of the Zip file name, however.
        Hide
        Dennis Hamilton added a comment -
        With regard to the movement of this discussion to the ODF TC JIRA, there are now the following issues under discussion:

        OFFICE-3342 (about the too-casual use of "IRI" in ODF 1.2 CD05 Parts 1-3)

        OFFICE-2685 (about the use of "IRI" specifically in ODF 1.2 CD05 Part 3 and the principles for how manifest:full-path and the Zip file name must agree for package files and what constraints are required to assure that they can be targets of path-noscheme URI references with IRI conventions.

        There are also earlier issues related to defect reports against ODF 1.0/IS 26300. The latest of these is at
        OFFICE-1826, <http://tools.oasis-open.org/issues/browse/OFFICE-1826>.
        Show
        Dennis Hamilton added a comment - With regard to the movement of this discussion to the ODF TC JIRA, there are now the following issues under discussion: OFFICE-3342 (about the too-casual use of "IRI" in ODF 1.2 CD05 Parts 1-3) OFFICE-2685 (about the use of "IRI" specifically in ODF 1.2 CD05 Part 3 and the principles for how manifest:full-path and the Zip file name must agree for package files and what constraints are required to assure that they can be targets of path-noscheme URI references with IRI conventions. There are also earlier issues related to defect reports against ODF 1.0/IS 26300. The latest of these is at OFFICE-1826 , < http://tools.oasis-open.org/issues/browse/OFFICE-1826 >.

          People

          • Assignee:
            Bart Hanssens
            Reporter:
            Bart Hanssens
          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: