search

sdmx-twg / sdmx-json

This repository is used for maintaining the SDMX-JSON message specifications.
54 stars 20 forks source link

Unclear source of min/maxOccurs property present in JSON schema of ConceptRepresentationType #124

Closed buhaiovos closed 1 year ago

buhaiovos commented 1 year ago

Hello!

According to the Information Model, section 4.5.3, concept might communicate its nature using Representation type.

4.5.3

It is described in more details in section 3.6.2, Fig. 15:

3.6.2

Json counterpart to that, in my understanding, is ConceptRepresentationType which described here, in json schema. This type contains minOccurs and maxOccurs fields for both enumerated and non-enumerated representations. But it is unclear (at least from the IM) where these values should be derived from.

Is somehow this communicated by the facets? But in case of Codelist representation - there are no facets present, just a reference to codelist. It seems that in the context of the Concept Scheme we don't know anything about the data which might be described by some concepts in question, so where we might get that information from? And what might be its usage given that there's no clear mapping of this information (min and max occurs) to the IM abstractions.

Really hoping for you help in understanding of this. Thank you!

dosse commented 1 year ago

Hello @buhaiovos, thanks for reporting this. It highlights an inconsistency in the documentation between the IM and the message format implementations (SDMX-ML and SDMX-JSON). Indeed, when constructing the message formats, sometimes some changes are made to generalise the approach and make it more coherent. Certain aspects may not have been seen when writing the IM document. The SDMX-JSON represents a translation of structures in SDMX-ML,.
You can see here how the maxOccurs and minOccurs parameters were moved from the component definitions into the RepresentationType, thus into CoreRepresentation (inside concepts) and LocalRepresentation (inside the component definitions in the DSD). The same was done in SDMX-JSON. In conclusion, it would seem to me that this feedback should be addressed by updating the IM document. I opened https://github.com/sdmx-twg/sdmx-im/issues/27 for this.

buhaiovos commented 1 year ago

@dosse, thanks for the response. So, basically, if we're dealing with such kind of issues (when something between infomodel and XML(JSON) doesn't match) - we consider message formats more relevant?

dosse commented 1 year ago

In general, the SDMX-ML schema is meant to be a "master" IM implementation. In many aspects, it is more precise. However, each issue need to be looked at separately, as bugs could also happen here.