Closed dosse closed 3 years ago
@sdmx3mdt Do you mean that a frequency dimension could be non-coded and thus have any type of value? In this case, the "FrequencyFormatMappingType" element name "FrequencyId" would be miss-leading and should rather be "FrequencyValue" since this doesn't necessarily concerns only identifiers.
@jgager grateful if you respond to Jens' question:
Do you mean that a frequency dimension could be non-coded and thus have any type of value? In this case, the "FrequencyFormatMappingType" element name "FrequencyId" would be miss-leading and should rather be "FrequencyValue" since this doesn't necessarily concerns only identifiers.
@dosse I agree that may FrequencyId implies a restriction that is not there. But we should confirm with @sdmx3mdt (Matt) that I do have the intention of this mapping correct.
@agent96 can you advise J?
@jgager I think you are right in that it could be a non ID Type in theory, but it probably makes sense to restrict it, as the chances of a user both not using a known SDMX Frequency ID and using an ID that does not conform to IDType would be very slim.
Fixed in release candidate working branch https://github.com/sdmx3mdt/sdmx-ml/tree/develop
Advice from J Gager As I understand this, it is intended to provide a date format based on frequency values. Since there is no restriction that says the values of a frequency dimension has to be of a given type, xs:string is appropriate. @dosse do you agree?