-
Notifications
You must be signed in to change notification settings - Fork 40
Description
There are many AASX in the wild that were created with an AASX package explorer version with the infamous eclipse-aaspe/package-explorer#161 Issue, where there was a www in the relationship definition that did not belong there.
The relationship URLs in question are:
http://www.admin-shell.io/aasx/relationships/aasx-origin
http://www.admin-shell.io/aasx/relationships/aas-spec
http://www.admin-shell.io/aasx/relationships/aas-spec-split
http://www.admin-shell.io/aasx/relationships/aas-suppl
whereas they should be according to the specification:
http://admin-shell.io/aasx/relationships/aasx-origin
http://admin-shell.io/aasx/relationships/aas-spec
http://admin-shell.io/aasx/relationships/aas-spec-split
http://admin-shell.io/aasx/relationships/aas-suppl
Since the specification only allows for the latter URLs (so the ones without the www), that means that the AASX are actually not standard compliant and need to be changed, though since there are so many of them, discussions (#379 #381) arose to nevertheless allow reading those AASX.
We deem it important to point out that there's a balance to be found regarding problems with the compliance towards the specification. The more non-compliance we accept, the less interoperable the whole system of AAS software becomes. Adherence to the specification is extremely important for the interoperability of AAS.
Nevertheless, if we end up being too strict, our software loses usability, and since there are so many non-compliant AASs (with this specific issue) in the wild, it only makes sense to be able to read them.
This is why we decided that our SDK should support reading the AASX files with wrong relationship URL, however with the caveat that this should a very noticable warning to the user who is reading that file.