[BUG] DataSpecification is missing but it's optional

[Padi2312]

I cant parse an AAS File with missing data specifications though its marked as optional (0..1) in the specs

[mristin]

Hi @Padi2312 ! Thanks for creating the issue!

Can you please send or copy/paste the JSON or XML file?

What SDK do you use (for which language, which version)?

[mristin]

Can you please also include the exact error message?

[Padi2312]

Hi @mristin

SDK: Typescript / v1.0.2 AASX File: Nerve_MFN200.zip (Note the AASX File is inside the ZIP because i cannnot upload files iwht ".aasx" Extension.

---

Instead of Copy/Paste the Data File I just provide you the whole AASX file. In order to use the given AASX file i use the the following AAS4J Library for converting the XML file to JSON.

After converting the Data File to JSON i am using the following to Deserialize the Object into the Environment Class aas.jsonization.environmentFromJsonable

There i get the following error object error_object.json

Thanks for your support.

[mristin]

Hi @Padi2312 , I had a look. Here are just some notes.

Given the environment that is included in the file error_object.json you attached, the de-serialization fails at submodels[2].submodelElements[2].value[0].value[0].embeddedDataSpecifications[0].

Here is a short Python snippet in case you want to reproduce it:

import aas_core3.jsonization as aas_jsonization
import aas_core3.verification as aas_verification

import json

with open("C:\\Users\\rist\\Desktop\\error_object.json") as fid:
    jsonable = json.load(fid)

environment_jsonable = jsonable["path"]["_segments"][0]["instance"]

try:
    environment = aas_jsonization.environment_from_jsonable(environment_jsonable)
except aas_jsonization.DeserializationException as exception:
    print(f"exception.path is {exception.path}")
    print(f"exception.cause is {exception.cause!r}")
    raise exception

Here is the problematic Property element:

{
  "modelType": "Property",
  "embeddedDataSpecifications": [
    {}
  ],
  "semanticId": {
    "keys": [
      {
        "type": "GlobalReference",
        "value": "0173-1#02-BAF016#005"
      }
    ],
    "type": "ExternalReference"
  },
  "value": "100",
  "valueType": "xs:float",
  "qualifiers": [
    {
      "semanticId": {
        "keys": [
          {
            "type": "GlobalReference",
            "value": "https://admin-shell.io/SubmodelTemplates/Cardinality/1/0"
          }
        ],
        "type": "ExternalReference"
      },
      "kind": "ConceptQualifier",
      "type": "Cardinality",
      "value": "ZeroToMany",
      "valueType": "xs:string"
    },
    {
      "semanticId": {
        "keys": [
          {
            "type": "GlobalReference",
            "value": "https://admin-shell.io/SubmodelTemplates/ExampleValue/1/0"
          }
        ],
        "type": "ExternalReference"
      },
      "kind": "ConceptQualifier",
      "type": "ExampleValue",
      "value": "Length",
      "valueType": "xs:string"
    }
  ],
  "category": "PARAMETER",
  "description": [
    {
      "language": "en",
      "text": "Width sometimes called length"
    },
    {
      "language": "de",
      "text": "Breite manchmal auch L\u00ef\u00bf\u00bdnge genannt"
    }
  ],
  "displayName": [
    {
      "language": "en",
      "text": "Width"
    },
    {
      "language": "de",
      "text": "Breite"
    }
  ],
  "idShort": "Width"
}

As you can see, the embedded data specification contains an empty object:

"embeddedDataSpecifications": [
    {}
  ]

According to the formalized meta-model, the embedded data specification must have the attributes dataSpecification and dataSpecificationContent: https://github.com/aas-core-works/aas-core-meta/blob/ae45d1e131ede272e22387eccac58e229e281872/aas_core_meta/v3.py#L5106-L5113

However, the attribute dataSpecification is marked as optional in the book (https://industrialdigitaltwin.org/wp-content/uploads/2023/06/IDTA-01001-3-0_SpecificationAssetAdministrationShell_Part1_Metamodel.pdf):

@s-heppner can you please have a look -- is this just an omission on our side when we formalized the meta-model, or did the meta-model change in the meanwhile?

The date of the book seems to be 2023-06 according to the URL.

This will also affect V3.1: https://github.com/aas-core-works/aas-core-meta/blob/ae45d1e131ede272e22387eccac58e229e281872/aas_core_meta/v3_1.py#L5106-L5110

[s-heppner]

I'm not entirely sure what happened here, but it could be related to admin-shell-io/aas-specs#377, which we found out due to this question: eclipse-basyx/basyx-python-sdk#231. There's confusion between when to use ModelReference and ExternalReference when referring to objects such as DataSpecifications.

Should the serialization create an

"embeddedDataSpecifications": [
    {}
  ]

object, even if there are no DataSpecifications to actually embed?

[mristin]

@Padi2312 @s-heppner please note that {} is an invalid EmbeddedDataSpecification -- the attribute dataSpecificationContent is mandatory, please see the crop from the book above.

[Padi2312]

@mristin As you provided in the image, the EmbeddedDataSpecification can be optional. But in my case there is an empty invalid object inside, what is your suggestion on handling this ?

Would you say the generated ASSX File I provided you, is per definition broken and shouldn't be used?

[mristin]

@Padi2312 thanks for clarification! 0..* should be serialized as omitted (no attribute specified) or as a list with at least one element.

So simply omit embeddedDataSpecifications in your JSON. (Note that it says embeddedDataSpecification in UML, but it's a list in JSON, so it reads embeddedDataSpecifications in JSON.)

Just a conclusion from my side: we need to fix EmbeddedDataSpecification and set its attribute dataSpecification to optional.

@s-heppner @zrgt I'll do that this Wed and propagate the change to schemas and SDKs for v3.

[Padi2312]

@mristin The reason for having this is Iusse is due to the environmentFromJsonable usage. In my case i want to parse the whole JSON, to use the Visitor pattern and get necessary data.

The problem appeared as I started using the whole Environment instead only a Submodel for parsing. (When only parsing the submodel the mentioned error doesn't appear, this would work as a workaround but isn't a good solution IMO)

I can't simply omit embeddedDataSpecification because i heavily rely on your Library for parsing the JSON (XML gets prior converted to JSON for usage) into a Environment Class.

[mristin]

@Padi2312 you have to fix the input manually then.

The snippet:

"embeddedDataSpecifications": [
    {}
  ]

is simply invalid according to the book (even with a bugfix -- the attribute dataSpecificationContent is mandatory, and you do not specify it in the snippet.

[s-heppner]

Just a conclusion from my side: we need to fix EmbeddedDataSpecification and set its attribute dataSpecification to optional.

@s-heppner @zrgt I'll do that this Wed and propagate the change to schemas and SDKs for v3.

As far as I can see, this has been an oversight from us and should be optional. However, I couldn't find a table defining class EmbeddedDataSpecification, the only time it seems to be mentioned in any of the specifications is that picture you posted above.

[mristin]

I'm propagating now the fix to the schemas and SDKs.

[mristin]

@Padi2312 the fix is propagated to all the schemas & aas-core SDKs.

@s-heppner @zrgt @sebbader-sap I recorded the latest schemas with the fix in the test data of aas-core-codegen, e.g., https://github.com/aas-core-works/aas-core-codegen/blob/main/test_data/xsd/test_main/aas_core_meta.v3/expected_output/schema.xsd

Please propagate them to https://github.com/admin-shell-io/aas-specs at your next convenience.

@wiresio the latest version including this fix of JSON-LD context is also recorded in the test data: https://github.com/aas-core-works/aas-core-codegen/blob/main/test_data/jsonld_context/aas_core_meta.v3/output/context.jsonld

[wiresio]

Nothing to do on our side. The context does not change if a property cardinality changes.

The change of property order from the schema has been handled in the PR of @mristin: https://github.com/aas-core-works/aas-core-codegen/pull/471/files#diff-4dd20b579b71841f8e1f84a9227ec8cec9b89c7c2f0854389a0e31dbfc78d25aR682

[s-heppner]

I've spoken to Birgit. This:

was a bug in the specification and has been adapted in the newest version of v3.0 (in preparation for v3.0.1).

class EmbeddedDataSpecification:
    dataSpecification: Reference must be: [1..1]

I will revert the changes in aas-core

[mristin]

So I need to revert all the SDKs? Oh, well...

[s-heppner]

I'm afraid so. Sorry that I only found out about it now.

[mristin]

Wait, has the new specs for V3 been published? I mean, we have to follow the book whatever its content. So which book are we actually following?

[s-heppner]

This is my current knowledge:

• There is the released spec v3.0 (which we fully adapted)
• There will be sometime soon a spec v3.0.1 (meaning bugfixes to v3.0)
• We are at the same time preparing a spec v3.1 (new version of the spec)

The spec v3.0.1 is not published yet and is still written in Word at the IDTA. Only v3.1 will be released as ASCIIDoc on GitHub.

Based on this, my current understanding was that we'd adapt the bugfixes of the spec v3.0.1 into aas-core3.0 and make a new release of the schema files and the SDK.

[mristin]

Let's wait till they publish v3.0.1 somewhere. Otherwise, the people will see the book, but of course be completely ignorant of this change, and create yet another issue.

[Padi2312]

@mristin I am sorry for the trouble I have caused you.

[mristin]

@mristin I am sorry for the trouble I have caused you.

Ah, no need to be sorry, all is good 😀.