xsiSchemaLocation in generated XML documents not processable by AASXPackageExplorer

[bs-jokri]

Hi,

I am currently trying to import AAS files in xml format generated by the AAS4j library into the AASXPackageExplorer, however it seems the editor cannot handle the xsi:schemaLocation produced by AAS4j.

The generated version contains a black before the file name

<aas:environment xmlns:aas="https://admin-shell.io/aas/3/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://admin-shell.io/aas/3/0 AAS.xsd">

However, the Editor loads the file, if it is provided as

<aas:environment xmlns:aas="https://admin-shell.io/aas/3/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://admin-shell.io/aas/3/0/AAS.xsd">

Expected behavior:
The generated XML file is imported into the AASXPackageExplorer.

[twebermartins]

Thanks @bs-jokri for raising this. We will have a look at it.

[FrankSchnicke]

I'm not sure if this is a bug related to AAS4J. In the schema location, pairs of namespaces as well as their respective schema location are provided. Thus, xsi:schemaLocation="https://admin-shell.io/aas/3/0/AAS.xsd" does not make much sense due to the file itself missing (i.e., the second entry in the schemaLocation tag). Nevertheless, it would make more sense to replace AAS.xsd with https://github.com/admin-shell-io/aas-specs/blob/V3.0.7/schemas/xml/AAS.xsd

Can you provide an error log of the AASX Package Explorer of an unsuccessful load?

[sebbader-sap]

I was not able to reproduce the described behaviour with AASX Package Explorer v2023-09-12.

However, what I did find out:

1. This minimal example can be loaded by the Package Explorer:

<?xml version='1.0' encoding='UTF-8'?>
<aas:environment xmlns:aas="https://admin-shell.io/aas/3/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://admin-shell.io/aas/3/0 AAS.xsd">
  <aas:assetAdministrationShells>
    <aas:assetAdministrationShell>
      <aas:id>AssetAdministrationShell---2CEBD072</aas:id>
      <aas:assetInformation>
        <aas:assetKind>Instance</aas:assetKind>
      </aas:assetInformation>
    </aas:assetAdministrationShell>
  </aas:assetAdministrationShells>
  <aas:submodels />
  <aas:conceptDescriptions />
</aas:environment>

2. AAS4J serialises this here (note the missing aas:submodels and aas:conceptDescriptions), which leads to an error:

<?xml version='1.0' encoding='UTF-8'?>
<aas:environment xmlns:aas="https://admin-shell.io/aas/3/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://admin-shell.io/aas/3/0 AAS.xsd">
  <aas:assetAdministrationShells>
    <aas:assetAdministrationShell>
      <aas:id>AssetAdministrationShell---2CEBD072</aas:id>
      <aas:assetInformation>
        <aas:assetKind>Instance</aas:assetKind>
      </aas:assetInformation>
    </aas:assetAdministrationShell>
  </aas:assetAdministrationShells>
</aas:environment>

[sebbader-sap]

As https://github.com/admin-shell-io/aas-specs/blob/2fe82a66ca502f9c5aea1ef0de0baaa729469faf/schemas/xml/AAS.xsd#L327 states that, e.g., submodels is optional but must not be empty, I see this as a bug in the Package Explorer.

[sebbader-sap]

@FrankSchnicke can you follow my arguments? If so, can you add it to the bug you have already opened in the Package Explorer?

[sebbader-sap]

(Remark: I had only a limited environment available for my tests, I was able to use v2023-09-12 but without needed .NET Core libraries - no permissions to install on my VM. Therefore, I am not 100% sure whether my Package Explorer behaves identical to others.)

[FrankSchnicke]

@sebbader-sap I added your findings to the ticket over at the AASX PE Repo: admin-shell-io/aasx-package-explorer#653.

@bs-jokri since @sebbader-sap could not reproduce the issue, I will close this ticket. For the general overview of compatibility issues related to bugs with AAS4J but also with AASX PE see #158

[bs-jokri]

@sebbader-sap @FrankSchnicke thanks to both of you looking into the issue. I also tested again and can second @sebbader-sap observations. My test model also missed some optional elements, which might caused the problem not the schemaLocation. Thus, fine with me closing the issue