Relationship targets do not follow the OPC

[andreas-schilling]

AASX Files that are written using AAS4J can't be read by libraries or tools that strictly follow the OPC. This is due to the fact, that the targets get their leading slash removed during serialization.
After some deeper investigation we narrowed this down to the ZIP marshalling of Apache POI, which is doing the following:

PackagingURIHelper.relativizeURI(sourcePartURI, targetURI, true)

(see also https://github.com/apache/poi/blob/trunk/poi-ooxml/src/main/java/org/apache/poi/openxml4j/opc/internal/marshallers/ZipPartMarshaller.java#L175)

The last boolean parameter drives the "MS Compatibility Mode" to generate URIs compatible with MS Office and OpenOffice and as a consequence removes leading slashes. JavaDoc for that parameter:

msCompatible - if true then remove leading slash from the relativized URI.
               This flag violates [M1.4]: A part name shall start with a forward slash ('/') character,
               but allows generating URIs compatible with MS Office and OpenOffice.

I know that as of now this situation is not under your control, especially as the parameter is obviously hardcoded and not even an option exists right now to change this from the outside.
Still I wanted to raise awareness for this issue so that a solution can be discussed.

[eliaspr]

This issue occurred to me, too, when I tried to read an .aasx file using a .NET library that seems to expect the target paths with a leading slash.

After doing some investigation on my own, I stumbled upon a few lines of code in the eclipse-basyx/basyx-java-sdk repository which look very similar except for one detail:

basyx-java-sdk (github link):

PackagePartName partName = null;
MemoryPackagePart part = null;
try {
    partName = PackagingURIHelper.createPartName(path);
    part = new MemoryPackagePart(root, partName, mimeType);
} catch (InvalidFormatException e) {
    // This occurs if the given MIME-Type is not valid according to RFC2046
    throw new RuntimeException("Could not create AASX Part '" + path + "'", e);
}

writeDataToPart(part, content);
root.registerPartAndContentType(part);
// set TargetMode to EXTERNAL to force absolute file paths
// this step is necessary for compatibility reasons with AASXPackageExplorer
relateTo.addRelationship(partName, TargetMode.EXTERNAL, relType, createUniqueID());

aas4j (github link):

PackagePartName partName = null;
MemoryPackagePart part = null;
try {
    partName = PackagingURIHelper.createPartName(path);
    part = new MemoryPackagePart(root, partName, mimeType);
} catch (InvalidFormatException e) {
    // This occurs if the given MIME-Type is not valid according to RFC2046
    throw new RuntimeException("Could not create AASX Part '" + path + "'", e);
}

writeDataToPart(part, content);
root.registerPartAndContentType(part);
relateTo.addRelationship(partName, TargetMode.INTERNAL, relType, createUniqueID());

The notable difference is the usage of TargetMode.EXTERNAL vs. TargetMode.INTERNAL along with a comment that suggests changing the flag to EXTERNAL would resolve the issue. However, I cannot judge at all whether this change would have some other implications. And there probably is some other reason for that difference.