SDMX 3.0: implement "feature 013 Reorganising constraints" for SDMX-ML 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

<str:DataConstraint agencyID="ECB" id="9d6e73af-93e7-44e8-a6e9-b28380f05dc4" type="Actual">
      <str:ConstraintAttachment>
            <str:Dataflow>
            <Ref package="datastructure" agencyID="ECB" id="EXR" version="1.0" class="Dataflow"/>
            </str:Dataflow>
            <str:Filter>A.EGP+RON..?startperiod=2010</str:Filter>
      </str:ConstraintAttachment>
      <str:CubeRegion include="true">
            <KeyValue id="COU">
                  <Value>AUS</Value>
                  <Value>AUT</Value>
            </KeyValue>
            <KeyValue id="VAR">
                  <Value>INDEX_2000</Value>
            </KeyValue>
            <KeyValue id="TIME_PERIOD">
                  <TimeRange>
                        <StartPeriod isInclusive="true">1990-01-01T00:00:00</StartPeriod>
                        <EndPeriod isInclusive="true">2017-12-31T23:59:59</EndPeriod>
                  </TimeRange>
            </KeyValue>
      </str:CubeRegion>
</str:DataConstraint>

• 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 in structure schemas by J

data message changes: no impact

[jgager]

@dosse @stratosn Can you confirm that MetadataTargetRegion/KeyValue should be removed (e.g. MetadataTargetRegion should only contain Attribute to state the allowed values for MetadataAttributes)? Section 2.3.2 and 2.3.3 left this somewhat ambiguous.

[stratosn]

Hi @jgager , yes I confirm that only Attributes are included in the MetadataTargetRegion. At some point, there were some objections on the name of the latter (i.e., if it should stay 'MetadataTargetRegion'), but we haven't managed to come up with a better name.

[jgager]

@stratosn, thanks. I will leave the name as is for now and we can change if/when a better one is found.

[dosse]

Released