-
Notifications
You must be signed in to change notification settings - Fork 19
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
Wrong Relationship Type in *.rels #161
Comments
I will raise an issue to support both relationship namespaces in Part 5 so that older .aasx can still be imported. admin-shell-io/aas-specs-aasx#2 (private repo) |
For people working with Package Explorer and products based on the Python Basyx library, we have released a tool that can convert from AASX files made with Package Explorer to a more Basyx compatible format. It works around this bug and bug admin-shell-io/temp-aasx-package-explorer#128. Find it at https://github.com/LukasBenner/AASFix |
Hi, |
Hi @JS-Aibel, in AAS4J (cf. eclipse-aas4j/aas4j#205) and in consequence, also in BaSyx, this is already fixed. However, I'm not sure about the AASX Package Explorer. Maybe @juileetikekar can add some details here. |
Thank you for the reply, @FrankSchnicke. |
This is most likely not related to this ticket but related to another ticket: admin-shell-io/aasx-package-explorer#654 However, to my knowledge, it will be fixed in the next release of the AASX Package Explorer (see the linked ticket for more infos, e.g., a draft PR). |
I propose that the explorer support both: |
For people working with Python Basyx library and Package Explorer, the following workaround worked for me. By changing the relationship type before calling the See Python code below.
|
I'm sorry to chime in, but that will create problems down the line with every other implementation that follows the specification precisely. As stated in the issue at the very beginning, the specification v3.0 requires " http://admin-shell.io/aasx/relationships", not " http://www.admin-shell.io/aasx/relationships". You're therefore advocating to create non-standard-conformant AASX packages that can only be read and written with the package explorer. Those files are broken for every other implementation that did follow the specification verbatim and missed this discussion here, or did not build a workaround. |
Thank you for your feedback, @s-heppner. What I usually do, is I create two files. One standard-conformant AASX packages. And another that has the extension |
That is also the way I understood it. @JS-Aibel 's post came at the perfect time to unblock my work (in my very early stage of exploring AAS use cases), but I will only use this hack to check that my |
Thanks for the clarification, @JS-Aibel and @timo-dreyer-mahr |
@martafullen Can you please move this issue back to the public repository? The topic is too relevant to keep it hidden here. |
@g1zzm0 this issue, as well as all the others in admin-shell-io/aasx-package-explorer, are being moved into the new official repo under eclipse-aaspe/aaspe. This process should be finished shortly and the discussion can continue there. Sorry for the confusion. P.S. this issue has been fixed and merged into main; it will be included in the next release |
PR #185 closes this issue. |
The AASX specification states on p. 17 that the namespace for relations is the following: http://admin-shell.io/aasx/relationships
In consequence, the relationship type in aasx-origin.rels has to be http://admin-shell.io/aasx/relationships/aas-spec; the relationship type in the general .rels has to be http://admin-shell.io/aasx/relationships/aasx-origin. However, the AASX Package Explorer and AAS4J as well are using http://www.admin-shell.io/aasx/relationships as namespace (note the extra "www").
In consequence, the AASX files created by the AASX Package Explorer and AAS4J are not conforming to the AASX spec on structural level. Fixing this by simply removing the "www" from the namespace string would lead to newer version of the AASX Package Explorer not being able to open files created before correcting this issue. In consequence, a backwards compatible solution looking for both namespaces would make sense.
We will fix this in AAS4J asap.
This issue was discovered due to the work of @s-heppner and team in the context of the BaSyx Python SDK 👍
The text was updated successfully, but these errors were encountered: