7.3.5 - pja - Association class - not supported in JSON

[PalmJanssen]

A question.

Why is there no proper support for an asscociation class in JSON other than redefining the association class as an intermediate class between two classes?

What is meant by a transformation of association classes as defined by GML 3.3? 1) Why referencing GML 3.3. The JSON transformation is independent of GML 3.3 2) Does GML 3.3 say that the UML association class needs to be redesigned as a UML asscociation before it can be transformed? If so, why not directly transforming without redesigning.? (reference also to 7.3.7)

Is there a support of association class in any other implementation?

[jechterhoff]

Afaics, JSON (Schema) simply does not have a construct that equals what an association class is. In JSON we only have objects with properties and their values (in addition to arrays and simple values). There is no such thing as a relation between two objects, especially not with the relation having properties of its own.

An example of the GML 3.3 transformation is shown in the OGC engineering report at http://docs.opengeospatial.org/per/16-020.html#rdf_cr_associationclass

Implementation technologies rarely support association classes directly. Right now I do not have an example that does support them.

[PalmJanssen]

Nicely explained in:

An example of the GML 3.3 transformation is shown in the OGC engineering report at http://docs.opengeospatial.org/per/16-020.html#rdf_cr_associationclass

I like the role names!

But if this is the standard redesign in the ApplicationSchema why not directly create the encoding result without redesigning? Or is information missing to do so?

[jechterhoff]

Good question. Imho, it is a matter whether the same transformation of the conceptual model should be defined in different encodings, or if that transformation is sort of "re-used".

Right now, we are re-using the transformation as defined in GML 3.3. To be exact, we currently give a recommendation (not explicitly stated as such) to apply that model transformation before applying a JSON Schema encoding rule. Do your schemas contain association classes?

[PalmJanssen]

To be exact, we currently give a recommendation (not explicitly stated as such) to apply that model transformation before applying a JSON Schema encoding rule.

Do you mean that the JSON encoding can also be done without first applying the UML model transformation? That is exactly what I mean and would be my recommended solution.

Do your schemas contain association classes?

The newly NEN 3610 allows association classes because they are intuitively explaining the semantics, and are part of UML. We also explain the implementation complications and the redesign option.

[jechterhoff]

Yes, the core requirements class could define the transformation directly, including explicit requirements. From the standpoint of standardized encoding of association classes in JSON Schema, that would be a good idea. Currently, since we do not have any such requirements, we sort of leave the door open for different encodings of association classes.

[lvdbrink]

I think since we do allow association classes and thus they can be encountered in UML models, it would be best to define this transformation + requirements for association classes.

[jechterhoff]

Decision: Do revise the section accordingly, to state the requirement(s) for the necessary model transformation (which a JSON Schema encoder would then have to perform on-the-fly).