Enable more than one DataSpecificationContent

[sebbader]

c116cf7 contains a working version for DataSpecificationIEC61360. However, were is already one other mentioned DataSpecificationTemplate in the specifications, namely DataSpecificationPhysicalUnit.

There are two options how to tackle this:

1. Create (recreate?) custom Deserialisers for DataSpecificationContent
2. Require an attribute similar to modelType in the schemas

[sebbader-sap]

I am in favour of option 1 as there won't be many DataSpecificationTemplates coming and a metamodel extension/extension of the schemas is not very realistic on short-notice.

[mjacoby]

The original implementation did support different DataSpecificationTemplates through the patter

 "embeddedDataSpecifications": [
         "embeddedDataSpecifications": {...},	// reference indicating the type
         "dataSpecificationContent": {...}		// actual data specification
     ]

However, the issue here is that in the future, eiter embeddedDataSpecifications or dataSpecificationContent but never both. So we need a way to encode the type information of the used DataSpecificationTemplate. This is currently not defined in the specification.

From my perspective, adding a modelType property would be a suitable approach consistent with the general concepts of de-/serialization. Not 100% sure how this will affect implementation but I guess it should not be to hard to implement.
Nevertheless, we should wait for standardization before starting implementation.

[sebbader-sap]

Updating the discussion as the V3.0RC02 has been released:
dataSpecificationContent has a modelType attribute now in JSON.

This means that we now have a stable pattern to implement as soon as the other, more important tasks for the V3.0RC02 migration have been solved.

[sebbader-sap]

Another update from the V3.0 schemas: There is only one DataSpecificationContent now: https://github.com/admin-shell-io/aas-specs/blob/e3a0798c2fb8b2bbacef76eede663f16045bd63f/schemas/json/aas.json#L356

Means, our current approach is correct for now just because there is no other candidate for "embeddedDataSpecifications/dataSpecificationContent" at the moment. Still, we should support the generic case but the importance - with this in mind - has changed from showstopper to good to have...

[FrankSchnicke]

Result of Committer Meeting today:

• This is a feature that we would like to include in V1.1 but not in V1
• In consequence, we should ensure that the current setup allows later modification without breaking changes

[FrankSchnicke]

Closed by #207