adapter.aasx: Allow reading AASX with wrong relationship

[jsejdija]

There are many AASX in the wild where there is an additional www in the relationship definition that does not belong there:

http://www.admin-shell.io/aasx/relationships/aasx-origin

whereas it should be according to the specification:

http://admin-shell.io/aasx/relationships/aasx-origin

Previously, our SDK did not allow for reading these AASX files with wrong relationship URL.
However, since there are so many of them, this change enables them to be read, while notifying the user with a big warning message that their AASX file is actually not standard compliant and needs to be changed (see discussion in #381).

Fixes #379
Fixes #383

[s-heppner]

Thank you a lot for your contribution!

The issue is well known (see also my comment in #379), but it is actually a problem with the specification compliance of the AASX, rather than with our SDK. (Here's the link to the relevant page in the specification).
I can see how making just the AASXReader less strict in this regard makes practical sense, as there are many non-compliant AASX in the wild.

We will discuss your suggestion in the next Dev-Team meeting and will get back to you.

[s-heppner]

Here's the result of the discussion in our meeting today:

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.

How should we proceed?
You can adapt your code that way, if you want to, and create an Eclipse Account to sign the contributor's agreement (the CI workflow that's currently failing in this PR, see these instructions). Otherwise, we will implement this ourselves for our next release.

[jsejdija]

I totally get your point and agree that the specification should be strictly followed. However, i came across this myself as many of the AASX examples from https://admin-shell-io.com/samples/ have the wrong/old relationship URL set.
Supporting these AASX files as well makes the tool more beginner friendly and usable for the AASX file-wildeness that exists 😆

I added a warning about the violation as you proposed.

Cheers

[s-heppner]

This code will make the core of the AASX readable by the AASXReader, meaning the JSON or XML file with the AAS data inside, but it may still mean that thumbnails or additional files are not properly found.

I've suggested to adapt the warning accordingly, to notify the user that they may not get the whole data out of the AASX and they still need to fix the file.

[s-heppner]

I've changed the target branch to our develop branch, since this is where we collect changes until the next release.

And of course, all CI checks need to run through before we can merge this.

[jsejdija]

Thanks for your suggestions, i fully applied them.

[s-heppner]

Thank you! The one check that is failing (sdk-docs) has nothing to do with you, as far as I can tell.
Please give me some time to investigate what happened there.

[s-heppner]

Okay, after some digging, this is in fact a dependency problem of our autodocumentation compiler (see #385).
Therefore, we can ignore this CI failing here for the moment.

The code now LGTM. I'll adapt your PR message slightly and merge it.
Thank you very much for contributing!