SDMX 3.0: implement "feature 013 Reorganising constraints" for SDMX-JSON messages

[dosse]

https://metadatatechnology.com/sdmx3/designs/013/approved/TF-2%20Reorganising%20Constraints%20v0.1.0.docx

[dosse]

In order to support the new requirement, it is proposed to:

structure message changes:

• When dynamic availability is requested through the availability query and a filter has been used, then the resulting response is a structure message containing a DataConstraints of type "actual" that includes the dynamic filter setting in the query as new "filter" part of the ContraintAttachment information as follow:

e.g. https://service-root/availability/ECB,EXR,1.0/A.EGP+RON..?startperiod=2010

    "contentConstraints": [{
        "id": "9d6e73af-93e7-44e8-a6e9-b28380f05dc4",
        "agencyID": "ECB",
        "type": "Actual",
        "constraintAttachment": {
            "dataflows": ["urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=ECB:EXR(1.0)"],
            "filter": "A.EGP+RON..?startperiod=2010"
        },
        "cubeRegions": [{
            "isIncluded": true,
            "keyValues": [
                {
                    "id": "COU",
                    "values": ["AUS","AUT"]
                },
                {
                    "id": "VAR",
                    "values": ["INDEX_2000"]
                },
                {
                    "id": "TIME_PERIOD",
                    "timeRange": {
                        "startPeriod": {
                            "period": "1990-01-01T00:00:00Z",
                            "isInclusive": true
                        },
                        "endPeriod": {
                            "period": "2017-12-31T23:59:59Z",
                            "isInclusive": true
                        }
                    }
                }
            ]
        }]
    }]

• Apply Semantic Versioning as described in ANNEX I
• Deprecate the AttachmentConstraint
• Split the ContentConstraint into 2 new separate artefacts: DataConstraint and MetadataConstraint but keep the "type" property. For DataConstraint, the "type" property can be "actual" or "allowed". For MetadataConstraint, the "type" property can currently only be "allowed".
• DataConstraints with the "type" property set to "actual" are always non-versioned.
• Constraints for reference metadata shall only contain one or more MetadataTargetRegions, i.e. specify the allowed values for MetadataAttributes
• The validity period for constraints shall be defined within the constraining terms (CubeRegion, DataKeySet and MetadataTargetRegion). ReferencePeriod??? (tbd)
• Attributes shall be allowed in DataKeySets, within each KeySet, to specify allowed Attribute values per Key

--> Implemented as translation from xml structure schemas by J

data message changes: no impact

[dosse]

Released