DIS 29500 currently allows applications to arbitrarily move and rename parts, providing the correct relationships are kept. However, this works against documents which are OPC-compliant and also contain data formats that do not use the OPC relationships system but hardcode locations.
For example, an OPC file that contains various JPEG images together with an HTML file that uses those images and the equivalent Open XML file. If the Open XML application renames the images, the HTML file will be out-of-date.
Add paragraph to DIS Part 1 s8.2 "A tool that acts both as a consumer and producer should not rename media files, at user option, unless the package has no unknown relationships."
Change any text relating to arbitrary renaming to make it strictly a user option, not the user default.
Part 1, s 8.2
te
Proposed Disposition of DIS 29500 Comment AU-0008 (Modified: 2008-01-04) One of the core concepts of the Open Packaging Convention is the use of relationships to specify references between parts, as described in Part 2, ยง8.2 ("Part Addressing"). The name of each part, however, is not defined and may be modified by consumers and producers. This allows for implementation of DIS29500 on a variety of software and hardware platforms, including environments that do not share identical support for filename conventions. For example, a consumer/producer running on an older operating system that is limited to 8-character filenames might extract parts and store them on disk, which would require that the names of those parts be truncated or otherwise modified. Because DIS29500 allows applications to rename parts, this would not be a problem and the consumer/producer could create a new document from these parts stored in the file system. Similarly, some environments do not support concepts such as subfolders. Again, this would not be a problem, because DIS29500 would allow a consumer/producer in that environment to move all parts into a single logical folder if necessary. These examples demonstrate how the lack of constraints on part names and locations serve to enable broad interoperability for DIS29500. As the commenter notes, such a lack of constraints "works against documents which are OPC-compliant and also contain data formats that do not use the OPC relationships system,"; however enabling these types of scenarios is outside the stated goals and scope of DIS29500. No changes to DIS29500 are proposed.
