Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relationship targets do not follow the OPC #300

Open
andreas-schilling opened this issue May 3, 2024 · 3 comments
Open

Relationship targets do not follow the OPC #300

andreas-schilling opened this issue May 3, 2024 · 3 comments

Comments

@andreas-schilling
Copy link
Contributor

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
Copy link

eliaspr commented May 28, 2024

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.

@alexgordtop
Copy link
Contributor

This issue was also raised at the IDTA Plugfest.

@andreas-schilling
Copy link
Contributor Author

Created an issue for Apache POI now as well: https://bz.apache.org/bugzilla/show_bug.cgi?id=69178

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants