You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In SDMX-ML Identifiables have @uri and @urn attributes and Maintainables have @serviceURL and @structureURL attributes. Links have @url and @urn attributes.
When asking an SDMX-REST web service to use external references in a response to reduce the size of a response, the client may very well have to interpret the links to resolve the external references.
Both SDMX-ML and SDMX-JSON also feature the rel attribute and suggest to use SDMX artefact types as link relations.
The external resources are referenced using self as link relation. That makes sense to me. But that leaves the question when you would ever use any of the SDMX artefact types as link relations.
For references that are important to the information model, like the conceptIdentity property, references are made via URNs without using the linking mechanism. And if artefacts referenced by URNs are also included in a message, possibly as stub, then you would again use self links to specify means of retrieval.
Now if my SDMX-JSON implementation relies on structure references always using the self relation, but some other implementer takes the suggestion to use artefact names as link relation to heart, my implementation cannot interoperate with the other implementation.
Note that shorthand link relations actually have to be registered, none of the SDMX artefact types have been registered as link relations in the IANA registry, and names like code or data are unlikely to be accepted into the registry with a SDMX-specific definition.
In conclusion, without a clear need to ever use SDMX artefact types as link relations, and considering them harmful to interoperability, and the behaviour of running code that does not use them either, I think this usage should be deprecated.
(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)
The text was updated successfully, but these errors were encountered:
In SDMX-ML Identifiables have
@uri
and@urn
attributes and Maintainables have@serviceURL
and@structureURL
attributes. Links have@url
and@urn
attributes.In SDMX-JSON as of https://github.com/sdmx-twg/sdmx-json/blob/71fe5eaa9fcd29e3c15f2f0216a19b9b650b1dbd/structure-message/docs/1-sdmx-json-field-guide.md these are all merged into
$..links[*]
.uri
,.urn
,.href
without explaining how the mapping is supposed to work.When asking an SDMX-REST web service to use external references in a response to reduce the size of a response, the client may very well have to interpret the links to resolve the external references.
Both SDMX-ML and SDMX-JSON also feature the
rel
attribute and suggest to use SDMX artefact types as link relations.In actual practise, and I guess the SDMX Global Registry for the IAEG SDG is a good and prominent example, https://registry.sdmx.org/sdmx/v2/structure/dataflow/IAEG-SDGs/DF_SDG_GLC/+/?format=sdmx-json&version=2.0.0&detail=allstubs&references=all does not work like that.
The external resources are referenced using
self
as link relation. That makes sense to me. But that leaves the question when you would ever use any of the SDMX artefact types as link relations.For references that are important to the information model, like the
conceptIdentity
property, references are made via URNs without using the linking mechanism. And if artefacts referenced by URNs are also included in a message, possibly as stub, then you would again useself
links to specify means of retrieval.Now if my SDMX-JSON implementation relies on structure references always using the
self
relation, but some other implementer takes the suggestion to use artefact names as link relation to heart, my implementation cannot interoperate with the other implementation.Note that shorthand link relations actually have to be registered, none of the SDMX artefact types have been registered as link relations in the IANA registry, and names like
code
ordata
are unlikely to be accepted into the registry with a SDMX-specific definition.In conclusion, without a clear need to ever use SDMX artefact types as link relations, and considering them harmful to interoperability, and the behaviour of running code that does not use them either, I think this usage should be deprecated.
(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)
The text was updated successfully, but these errors were encountered: