[Bug]: JSON mapping: Class Common:NamedArea not created in Schema

[VictoriaSteinerAC]

What happened?

When creating JSON schema from the current (v3.5) preassembled Common model, no class is created for "NamedArea" (neither "NamedArea" nor "NamedAreaG"). Since it is an abstract class only the "NamedAreaG" should be generated. However, the attribute "namedArea" in class "SpecialDay" and "PublicHoliday" refer to "DATEXII_3_Common.json#/definitions/NamedArea", which is not specified in the schema for Common.

Version

3

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[jonas-jaderberg]

SpecialDay has "namedArea": { "type": "array", "items": { "$ref": "DATEXII_3_Common.json#/definitions/NamedAreaG" }, "minItems": 0 },

NamedAreaG in Common looks like "NamedAreaG": { "type": "object", "additionalProperties": false, "properties": { "locNamedArea": { "$ref": "DATEXII_3_LocationReferencing.json#/definitions/NamedArea" }, "locNutsNamedArea": { "$ref": "DATEXII_3_LocationReferencing.json#/definitions/NutsNamedArea" }, "locIsoNamedArea": { "$ref": "DATEXII_3_LocationReferencing.json#/definitions/IsoNamedArea" }, "locxNamedAreaExtended": { "$ref": "DATEXII_3_LocationExtension.json#/definitions/NamedAreaExtended" } } }

This is cretaed by the polymorphism rules i.e we transforms inheritance to associations for possible children.

As I see, it it looks correct I looked at the schemas generated for 3.5 release under v3_support\Schema\JSONSchema\Published schema

[VictoriaSteinerAC]

That's strange. I used the current tool (from the DevOpS Repo) with the v3.5 pre-assembled Common model from from datex2.eu. And I get the following for SpecialDay: And "NamedAreaG" cannot be found.

[VictoriaSteinerAC]

Maybe the problem is that I use the pre-assembled Common model where there is no Location namespace? Since NamedArea is an abstract hook class, this case is different than the one you have tested where there is also the Location namespace in the model.

[jonas-jaderberg]

Yes, that is the problem. A G class was not generated because tha abstract class didn't have a subclasss, in your model. I think we should always generate a G class.

[paalaas]

Should we then generate for all abstract class, not very useful to only generate a class like this, but then it will at least validate?

[JosefKaltwasserAC]

Please, note the intensive discussion thread on namespace dependencies we had via the tb@datex.eu reflector. This is among the JSON Schema issue we should discuss in the TB. In all mappings based on flattening, you cannot 'transfer' the created schemas. you always have to create the full model on UML level and then create the consistent set of schemas. If you take the Common schema created from the full model, it is dependent on all existing namespaces, since PayloadPublicationG will refer to all possible publications. We should also consider wether that has implications regarding the use of Exchange2020.