xsd.2_0.SDMXStructure.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of SdmxSourceUtil Show documentation
Show all versions of SdmxSourceUtil Show documentation
Open source reference implementation of SDMX
The newest version!
OrganisationSchemesType contains one or more OrganisationSchemes.
OrganisationSchemeType contains the details of an OrganisationScheme. In OrganisationSchemes, the organisation roles of agency, data provider, and data consumer may be specified. A single organisation may play more than one role. Name is an element which provides for a human-readable name for the organization. Description may be used to provide a longer, human-readable description. the is attribute provides a formal ID for the organisation scheme; the version attribute specifies a particular version. If blank, it is assumed that the version is "1.0". The uri attributre specifies the location of a valid SDMC Structure Message containing the full details of the organisation sc`heme, and is required if the isExternalReference attribute has a value of true. If isExternalReference has a value of false, full details must be provided in the current instance of the OrganisationScheme element. The urn attribute provides a formal SDMX Registry URL - see the Logical Registry Specification for specific requirements. An agencyID must be provided, identifying the maintenance agency of the organisation scheme. Also, if the organisation scheme is final, the isFinal attribute must have a value of true - otherwise, it will be assumed to be non-final. (All production schemes must be made final - that is, unchangeable without versioning.) The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
DataProvidersType contains one or more data providers. Data providers are those who report or disseminate data sets or metadata sets.
DataConsumersType contains one or more data consumers. Data consumers collect or use disseminated data sets and metadata sets.
AgenciesType contains one or more Agencies. Agencies are those organisations which act as the maintainers of structural definitions of various types. Agencies are often supplied as part of an organisation scheme, but may also be supplied independently using this element.
OrganisationType provides a structure for describing agencies, data providers, and data consumers and their contact information. The id attribute carries a code identifying the agency. The version attribute indicates the version of the agency description. The uri attribute provides a uri for an alternate way of identifying the agency information (typically a URL resolving to an agency described in SDMX-ML). Name is an element which provides for a human-readable name for the organization. Description provides for a longer human-readable description of the organisation, which may be provided in multiple, parallel language-equivalent forms. MaintenanceContact provides contact information for the agency when acting as a MaintenanceAgency; CollectorContact does the same when the agency is acting as a statistics collector; DisseminatorContact for when the agency functions as a statistics disseminator; and ReporterContact for when the Agency is functioning as a statistics reporter. OtherContact is used to describe any other role. Note that the Role field in the contact information structure should only be specified for OtherContact. It is allowable to reference full Agency information by using (at a minimum) only the id, name, and uri fields, with the uri pointing to an external description in a valid SDMX-ML Structure message which provides more complete information. (This is termed an "external reference".) If an external reference is being made, the isExternalReference attribute must be set to "true". The urn attribute holds a valid SDMX Registry URN (see SDMX Registry Specification). The parentOrganisation attribute holds the id of a parent organisation of the same type from the same scheme, indicating that the organisation in question is a department or other sub-division of the parent organisation. Annotations may be provided using the Annotations element, in multiple, parallel-language form.
ContactType provides defines the contact information about a party. The id element is used to carry user id information for the contact, whereas Name provides a human-readable name.
DataflowsType contains one or more data flows.
DataflowType describes the structure of a data flow. A human-readable name must be provided, and may be given in several language-specific variations. A longer human-readable description (also in multiple language-specific versions) may be provided. A reference must be made to a key family, and to a category within a category scheme, using the KeyFamilyRef and CategoryRef elements, unless the Dataflow is a reference to an external data flow, in which case a url must be provided in the uri attribute, and the isExternalReference attribute must be set to true.. Annotations may be provided in the Annotations element. An id unique to the maintaining agency (identified in the agencyID attribute) must be supplied in the "id" attribute; a version may be specified, and is assumed to be "1.0" if not supplied. The urn attribute may contain a valid registry URN (as per the SDMX Registry Specification). If the dataflow is final, the isFinal attribute must have a value of true - any production dataflow must be final (that is, it cannot be changed without versioning). The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
KeyFamilyRefType provides a reference to a key-family (data set structure definition). At a minimum, either (a) The key family ID must be provided, as assigned to the key family by the agency whose ID is the value of KeyFamilyAgencyID. A version must also be provided; OR (b) a valid SDMX Registry URN must be provided in the URN element (see SDMX Registry Specification)
CategoryRefType provides a reference to a category. At a minimum, either a value for CategorySchemeAgencyID, CategorySchemeID, and CategoryID must be provided, or a valid SDMX Registry URN must be provided in the URN element (see SDMX Registry Specification).
CategoryIDType describes a structure which can provide a path inside a hierarchical category scheme. Each node (category) of the referenced scheme is represented by a CategoryID element, with sub-categories represented by the child CategoryID element. Each CategoryID element must be given a node identifier in the ID field, which corresponds to the ID of the category. It is not necessary to represent the full category path with the nesting structure if each node within the hierarchical category scheme has a unique id.
MetadataflowsType contains one or more metadata flows.
MetadataflowType describes the structure of a metadata flow. A human-readable name must be provided, and may be given in several language-specific variations. A longer human-readable description (also in multiple language-specific versions) may be provided. A reference must be made to a metadata structure definition, and to a category within a category scheme, using the MetadataStructureRef and CategoryRef elements. If the Metadataflow is an external reference, this is indicated by setting the isExternalReference attribute to true, and providing a url where the full description can be found in the form of a valid SDMX-ML structure message. In this case, only the id and name must be provided. Annotations may be provided in the Annotations element. An id unique to the maintaining agency (identified in the agencyID attribute) must be supplied in the "id" attribute; a version may be specified, and is assumed to be "1.0" if not supplied. The urn attribute may contain a valid registry URN (as per the SDMX Registry Specification). If the metadata flow is final, the isFinal attribute must have a value of true - any production metadata flow must be final (that is, it cannot be changed without versioning). The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
MetadataStructureRefType provides a reference to a metadata structure definition. The ID must be provided, as assigned to the metadata structure definition by the agency whose ID is the value of MetadataStructureAgencyID. A version must also be provided.
CategorySchemesType contains one or more category schemes.
CategorySchemeType describes the structure of a category scheme. This is a simple, levelled hierarchy. The scheme itself is given a human-readable name (which may be in multiple language-specific versions), and may optionally have a human-readable description (also in multiple, landuage-specific versions). Annotations may be provided in the Annotations element. The Category element represents a set of nested categories which describe a simple classification hierarchy. The CategoryScheme must have an agency specified in teh agency attribute, and a unique ID provided for all of the category schemes of that agency in the id attribute. A version may also be supplied - if ommitted, the version is understood to be "1.0". If the isFinal attribute has a value of true, the category scheme is final and cannot be changed without versioning. All production category schemes must be final. The urn attribute holds a valid registry URN (see the SDMX Registry Specification). If the isExternalReference attribute has a value of true, then the uri attribute must have a value which provides the location of a valid SDMX Structure message providing full details of the Category Scheme. Otherwise, all details must be provided here. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
The category is given a human-readable name (which may be in multiple language-specific versions), and may optionally have a human-readable description (also in multiple, landuage-specific versions). Annotations may be provided in the Annotations element. References to dataflows and metadataflows may be provided. The Category element represents a set of nested categories which are child categories. The Category must have a unique ID within the Category Scheme provided in the id attribute. A version may also be supplied - if ommitted, the version is understood to be "1.0". The urn attribute holds a valid registry URN (see the SDMX Registry Specification).
CodelistsType contains one or more codelists. It also defines uniqueness constraints for codelist IDs.
CodeListType defines the contents of a codelist. This includes an ID, the agency which maintains the codelist, its version, and a URL where it is located. Elements are provided for supplying a name and the codes. It is acceptable to provide only the id, name, and uri fields at a minimum, with the uri pointing to an SDMX Structure message containing complete details on the codelist. (This is termed an "external reference".) If an external reference is being made, the isExternalReference attribute must be set to "true". The urn attribute holds a valiud SDMX Registry URN (see SDMX Registry Specification). The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
CodeType defines the structure of a code. This allows for plain-text descriptions as element content, and the coded value as the value attribute. (Short descriptions or other presentational information may be added using Annotations with an indicative type field [eg, "ShortDescription"]). The urn attribute supplies a valid SDMX Registry URN (see the SDMX Registry Specification).The parentCode attribute provides the ability to describe simple hierarchies within a single codelist, by referenceing the id value of another code in the same codelist.
HierarchicalCodelistsType contains one or more sets of structural information about the hierarchies within a codelist (hierarchical codelists). This corresponds to complex hierarchical codelists within the SDMX Information Model - very simple hierarchies can be described within the regular Codelist, using the parentCode attribute.
A hierarchical codelist references a Codelist, and supplies the extra structural metadata to assemble the codes into a hierarchy. A human-readable name must be supplied, and multiple language-specific variants may be provided. A longer human-readable description may be provided, and may also be presented as a set of language-specific variants. The CodelistRef element references a codelist, and may indicate more than one. Annotations may be provided in the Annotaions element. An ID unique for the agency specified in the agency attribute must be assigned, using the id attribute. A version may be provided using the version attribute - if no value is provided, it is assumed to be "1.0". A valid SDMX Registry URN may be provided in the urn attribute, as specified in the SDMX Registry Specification. If the isExternalReference attribute has a value of true, the uri attribute must specify the location of a valid SDMX Structure Message which provides the full details of the hierarchical codelist; otherwise, all details must be present. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
The recursive CodeRef element is used to assemble the codes in the codelist(s) referenced by the parent hierarchical codelist into a hierarchy. The Level element is used to describe the levels of a levelled hierarchy, which may be referenced from each of the CodeRefs in the Hierarchy. A human-readable name must be assigned, which may be provided in multiple, parallel-language versions. A longer, human-readable Description may also be provided, which can also have multiple parallel-language versions. Annotations may be provided with the Annotations element. The id attribute provides a unique id for the hierarchy. The urn attribute can be used to specify the hierarchy with a valid SDMX Registry URN (see the SDMX Registry Specification). The version attribute specifies a version (understood to be "1.0" if not specified), and isFinal, once given a value of true, indicates that nothing may be changed without also changing the version number. validFrom and validTo are inclusive dates indicating the relevant period of the hierarchy.
LevelType describes a level in a hierarchical codelist. The Order element specifies where the level is in a levelled hierarchy, starting with the value "1" for the top level, and going sequentially from there using whole integers. CodingType specifies the text formatting of the codes at that level. A human-readable name must be assigned, which may be provided in multiple, parallel-language versions. A longer, human-readable Description may also be provided, which can also have multiple parallel-language versions. Annotations may be provided with the Annotations element. The id attribute provides a unique id for the hierarchy. The urn attribute can be used to specify the hierarchy with a valid SDMX Registry URN (see the SDMX Registry Specification).
The CodelistRefType provides the structure for a codelist reference. (Note that this is structured differently than a similarly-named type in the Registry namespace.) At a minimum, either: AgencyID has the ID of an agency as a value; CodelistID takes the ID of a codelist maintained by that agency; and Version specifies the version of the codelist; or URN supplies a valid SDMX Registry URN (see the SDMX Registry Specification). Alias is used to carry the identifier for the referenced codelist, so that codes from that list can be easily referenced by the CodeRefs contained in the parent Hierarchy, without having to repeat the agency and version for each reference. The Alias must be unique within the parent Hierarchical Codelist.
The CodeRefType provides the structure for a codelist reference. At a minimum, either a URN value (a valid SDMX Registry URN as specified in teh SDMX Registry Specification) must be supplied, or a ColdelistAliasRef and a CodeID must be specified. CodelistAliasRef references an alias assigned in a CodelistRef element in the containing hierarchical codelist.CodeRef references a code from the codelist identified at the level of the parent hierarchical codelist. Codes are arranged in a hierarchy by reference. Note that it is possible to reference a single code such that it has multiple parents within the hierarchy. Further, the hierarchy may or may not be a levelled one. CodeID holds the ID of the code in the codelist referenced by the hierarchical codelist. CodeRef references a code. LevelRef holds the id of a Level described in the same parent Hierarchical Codelist. NodeAliasID allows for an ID to be assigned to the use of the particular code at that specific point in the hierarchy. This value is unique within the hierarchy being created, and is used to map the hierarchy against external structures. Version holds the version number of the referenced code, to support management of complex hierarchies. Along with this field are the ValidFrom and ValidTo dates, which are inclusive dates during which the code is valid within the parent hierarchy.
The ConceptsType describes an XML type which contains information about sets of concepts and their relationships, each of which is described in a ConceptScheme element. This section replaces the section of the version 1.0 SDMXStructure message which provides details about concepts. As such, it is backward-compatible, and may be used to contain a simple list of concepts as per the 1.0 SDMX-ML specification.
ConceptType specifies the information provided for a single concept. This includes a name, as element content, and an ID. It is possible to use the uri field to point to the location of an SDMX-ML Structure message which contains a more detailed version of the concept. (This is termed an "external reference".) If an external reference is being made, the isExternalReference attribute must be set to "true". In this case, all details of the concept are assumed to be found externally, and inline characteristics provided through child elements and the coreRepresentation and coreRepresentationAgency attributes are to be ignored. The coreRepresentation and coreRepresentationAgency attributes can identify a codelist which is a default representation of the concept. Uncoded default representations (or information about the textual aspects of coded default representations) can be provided with the TextFormat child element of the concept. Semantic relationships between concepts which occur within a single concept scheme can be captured with the parent and parentAgency attributes - these identify the concept of which the current concept is a qualification (in the ISO 11179 sense) or subclass. When used outside of a containing ConceptScheme, these attributes may be ignored. If a coreRepresentation and core RepresentationAgency are not provided, but are provided in the indicated parent, then the default representation is inherited from the specified parent concept. Note that all concepts within a concept scheme must be uniquely identified by their id - each concept scheme has only one agency for all its concepts. The agency attribute here is provided for backward-compatibility with version 1.0 of the standards, and it must not be used for concepts which are child elements of a concept scheme.
ConceptSchemeType describes the structure of a ConceptScheme element, which is the preferred form (as of version 2.0) of presenting the concepts used in other SDMX constructs. ConceptSchemes may be included inline (that is, with all details provided in the instance or may be referenced externally. It is possible to use the uri field to point to the location of an SDMX-ML Structure message which contains a more detailed version of the concept. (This is termed an "external reference".) If an external reference is being made, the isExternalReference attribute must be set to "true". A Name may be provided as a child element (in multiple parallel language versions) and an ID and version and agency information may be provided. ConceptSchemes represent a collection of concepts which are used to describe a meaningful set of distinct concepts, to be used in the reporting of data or metadata. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
MetadataStructureDefinitionsType describes one or more metadata structure definitions.
A metadata structure definition performs several functions: it groups sets of objects into "targets" against which reference metadata may be reported. Targets define the structure of the reference metadata "keys" which identify specific types of reported metadata, and describe the valid values for populating the keys. Also, metadata structure definitions provide a presentational organization of concepts for reporting purposes. The structure of a reference metadata report is derived from this presentational structure. Also, representations - unless defaults from the concepts are used - must be indicated as part of this presentational structure. Attributes allow the assignment of an ID, an agency, a version, and a uri. It is possible to use the uri field to point to the location of an SDMX-ML Structure message which contains a more detailed version of the metadata structure definition. (This is termed an "external reference".) If an external reference is being made, the isExternalReference attribute must be set to "true". When an external reference is being made, none of the child elements should be included. Otherwise, both TargetIdentifiers and at least one ReportStructure must be included. The urn attribute holds a valid SDMX registry URN (see the SDMX Registry Specification). The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
TargetIdentifiers are the set of objects against which reference metadata is reported (data providers, data flows, data or metadata structures, etc.). There are two types of TargetIdentifiers: the "full" target identifier, which lists every object used to attach metadata to in the metadata structure definition, and the partial target identifiers, which indicate sub-sets of those concepts against which reference metadata may be reported. It is sometimes the case that metadata will also be reported against the full target identifier.
An example of this is as follows: we might wish to collect some metadata concepts such as contact information for some of the objects described by the SDMX Information Model - for each instance of a metadata flow or a data provider, for example. Our concepts would be the concepts associated with contact information: CONTACT_NAME, CONTACT_PHONE_NUMBER, etc. We would determine how these concepts are associated with the objects in the model: do we want a contact for each data provider broken out by data flow? Or do we want only a single contact reported for each data provider (who might provide several data flows)? Each object or combination of objects we need to have metadata reported for becomes a partial target identifier, unless it happens to contain the full target identifier, in which case we use that instead. Thus, our valid partial target identifiers here would be "data flow" and "data provider", because "data flow by data provider" is a full target identifier. For each target identifier, we could have some set of our concepts reported.
The full target identifier provides details on all of the objects against which metadata can be reported. The full target identifier is made up of a set of identifier components - each getting its own child element - which are similar to the dimensions of a key family: each one indicates that a value will be provided by the metadata reporter to identify and describe the metadata being reported. A human-readable name must be provided, which may be provided in multiple, parallel-language versions. A longer, human-readable name may also be provided in multiple, language-parallel versions. Annotations may be provided.
An identifier component describes the use of an object within the full target identifier set. An identifier component must be one of the formally-recognized object classes found in the SDMX Information Model: the sub-element TargetObjectClass provides a way of indicating which objects will be used in reporting metadata, and will indicate how those objects are to be identified by the metadata reporters (which value sets will be allowed for each identification field for each object). The RepresentationScheme child element is used to indicate the valid range of values for the providing taget identifiers in reported metadata.
Partial target identifiers are subsets of the full target identifier. They are themselves given an identifier, so that they can be referenced by the metadata attributes of a report. A human-readable name must be provided, which may be provided in multiple, parallel-language versions. A longer, human-readable name may also be provided in multiple, language-parallel versions. Annotations may be provided.
The Object ID is used to reference a particular Object within the SDMX Information Model's formalization of statistical exchanges.
Agency
Concept scheme
Concept
Codelist
Code
Key family
Component
Key descriptor
Measure descriptor
Attribute descriptor
Group key descriptor
Dimension
Measure
Attribute
Category scheme
Reporting taxonomy
Category
Organisation scheme
Data or metadata provioder
Metadata structure definition
Full target identifier
Partial target identifier
Metadata attribute
Data flow
Data or metadata provision agreement
Metadata flow
Content constraint
Attachment constraint
Data set
Cross-sectional data set
Metadata set
Hierarchical codelist
Hierarchy
Structure set
Structure map
Component map
Codelist map
Code map
Category scheme map
Category map
Organisation scheme map
Organisation role map
Concept scheme map
Concept map
Process
Process step
Representation schemes indicated which values are valid for identifying objects within each class. For any given representation scheme, two IDs must be provided: the RepresentationScheme must have an ID as assigned to it by it representationSchemeAgency, whose ID must also be provided. The type of the representation scheme is expressed in the representationSchemeType attribute.
The report structure describes the presentation of the reported concepts, and associates them with target identifiers, full or partial. It can be given a name and/or annotations. It must be given an ID, using the id attribute, which must be unique within the MetadataStructureDefinition element. It contains one or more MetadataAttribute elements, each of which may either hold a value, or may have subordinate MetadataAttribute elements. The target attribute holds the ID of a full or partial identifier, which is the identifier of the target against which the metadata attributes are reported.
Metadata attributes are those concepts - whether taking a coded or uncoded value, or made up of child concepts, or both - which are reported against a full or partial target identifier. If there are nested metadata attributes, these concepts are subordinate to the parent metadata attribute - that is, for the purposes of presentation, the parent concept is made up of the child concepts. This hierarchy is strictly presentational, for the purposes of structuring reports. If the metadata attribute can have a coded or uncoded value, then the charateristics of the value are indicated with the TextFormat child element. If the value is coded, then the representationScheme and representationSchemeAgency attributes must hold values: the representationScheme attribute takes the ID of a representation scheme, and the representationSchemeAgency takes the ID of the agency which maintains that scheme. The conceptRef attribute holds the ID of the metadata attribute's concept. The conceptAgency attribute takes the agency ID of the concept referenced in conceptRef. The conceptSchemeRef attribute holds the ID value of the concept scheme from which the concept is taken, and the conceptSchemeAgency holds the ID of the agency that maintains the concept scheme referenced in the conceptSchemeRef attribute. The useageStatus attribute indicates whether provision of the metadata attribute is conditional or mandatory.
TextFormatType defines the information for describing a text format. If the TextType attribute is not specified, any valid characters may be included in the text field. (It corresponds to the xs:string datatype of W3C XML Schema.) The textType attribute provides a description of the data type, and may place restrictions on the values of the other attributes, referred to as "facets". The isSequence attribute indicates whether the values are intended to be ordered, and it may work in combination with the interval attribute. The minLength and maxLength attributes specify the minimum and maximum lengths of the value in characters. startValue and endValue are used for inclusive and exclusive ranges, indicating what the bounds of the range are. The interval attribute specifies the permitted interval between two values. The timeInterval attribute indicates the permitted duration between two time expressions. The decimals attribute indicates the number of characters allowed after the decimal separator. The pattern attribute holds any regular expression permitted in the simila facet in W3C XML Schema.
TextTypeType provides an enumerated list of the types of characters allowed in a TextFormat field.
A string datatype corresponding to W3C XML Schema's xs:string datatype.
An integer datatype corresponding to W3C XML Schema's xs:integer datatype.
An integer datatype corresponding to W3C XML Schema's xs:int datatype.
A numeric datatype corresponding to W3C XML Schema's xs:long datatype.
A numeric datatype corresponding to W3C XML Schema's xs:short datatype.
A numeric datatype corresponding to W3C XML Schema's xs:decimal datatype.
A numeric datatype corresponding to W3C XML Schema's xs:float datatype.
A numeric datatype corresponding to W3C XML Schema's xs:double datatype.
A datatype corresponding to W3C XML Schema's xs:boolean datatype.
A time datatype corresponding to W3C XML Schema's xs:dateTime datatype.
A time datatype corresponding to W3C XML Schema's xs:date datatype.
A time datatype corresponding to W3C XML Schema's xs:time datatype.
A time datatype corresponding to W3C XML Schema's xs:gYear datatype.
A time datatype corresponding to W3C XML Schema's xs:gMonth datatype.
A time datatype corresponding to W3C XML Schema's xs:gDay datatype.
A time datatype corresponding to W3C XML Schema's xs:gMonthDay datatype.
A time datatype corresponding to W3C XML Schema's xs:gYearMonth datatype.
A time datatype corresponding to W3C XML Schema's xs:duration datatype.
A datatype corresponding to W3C XML Schema's xs:anyURI datatype.
A complex datatype specifying a start date (xs:dateTime) and a duration (xs:duration). Note that this is not allowed as thre text type representing a dimension.
A simple incrementing Integer type. The isSequence facet must be set to true, and the interval facet must be set to "1".
This value indicates that the startValue and endValue attributes provide an inclusive numeric range of type xs:double.
This value indicates that the startValue and endValue attributes provide an exclusive numeric range, of type xs:double.
This value indicates that the value increments according to the value provided in the interval facet, and has a true value for the isSequence facet.
This is a time datatype, and is the conventional representation of time in SDMX formats. It is a union of W3C XML Schema time datatypes and a set of codes for indicating quarterly, tri-annual, bi-annual, and weekly time periods. See common:TimePeriodType for specifics.
UsageStatus provides a list of enumerated types for indicating whether reporting a given metadata attribute is mandatory or conditional.
Reporting the associated attribute is mandatory - a value must be supplied.
Reporting the associated attribute is not mandatory - a value may be supplied, but is not required.
Representation scheme type provides an enumerated list of valid types of representation schemes.
Representation scheme is a codelist.
Representation scheme is a concept scheme.
Representation scheme is a category scheme.
Representation scheme is an organisation scheme.
Representation scheme is "external" to the known model - that is, it cannot be enumerated at the time the report is designed. This will only be valid if some maintained and changing object is to have metadata reported against it: for example, if the concepts of dimension objects are to be reported against for all of an agencies' key families, then it is not possible at design time to enumerate all of the concepts which will be used by that agencies' key families into the future. This value should not be used unless absolutely necessary, as it reduces the processability of the metadata report generated.
KeyFamiliesType defines the structure for describing one or more key families. It also provides uniqueness constraints for each of the key family IDs.
KeyFamilyType defines the structure of a key-family description. This includes the name and a set of components (attributes and dimensions) as element content, and an ID, agency, version, and the URL where located as attributes. The urn attribute holds a valid SDMX Registry URN, as per the SDMX Registry spec. The isFinal attribute, once set to true, indicates that no changes may be made without versioning. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version. If the isExternalReference attribute is true, then the uri attribute must be provided, giving a location where a valid structure message can be found containing the full details of the key family.
ComponentsType describes the dimensions, groups, attributes, and measures of the key family. If TimeDimension is included in the key family - which it must be if time series formats for the data (GenericData, CompactData, and UtilityData formats) are to be used - then there must also be a frequency dimension.
DimensionType describes the structure of non-Time dimensions. The order of their declaration is significant: it is used to describe the order in which they will appear in data formats for which key values are supplied in an ordered fashion (exclusive of the Time dimension, which is not represented as a member of the ordered key). Some types of non-Time dimensions have un-coded values: the TextFormat element must be provided, to indicate what type of values are permissible. The attributes isFrequencyDimension and isEntityDimension may have a "true" value for any instance of the Dimension element, indicating that it is a dimension of the stated type. The attributes isCountDimension, isNonObservationalTimeDimension, isMeasureDimension, and is IdentityDimension may occur multiple times, and take a true value to indicate that the diemsnion in question is of that type. Note that only one dimension in the key family may be of the following types: Frequency dimension and Entity dimension, and only if there is not also an attribute in the key family of the same type. Any given dimension may only have a true value for one of the set of attributes isFrequencyDimension, isCountDimension, is measureDimension, isEntityDimension, isNonObservationalTimeDimension, and is IdentityDimension. The definitions and limits on representation of each dimension type are as follows: Frequency dimension describes the period between observations, and is coded; Count dimensions are represented by values which are sequential, incrementing numbers - representations are always of the Increment or Count type; measureType dimensions are always coded, and they enumerate the set of possible measures declared for the key family; Entity dimensions describe the subject of the data set (ie, a country) - they can be coded or represented in any other form; Non-Observational Time dimensions must have a representation which contains a time; Identity dimensions may be coded or uncoded, but must be represented by a scheme which refers to the identifiers of external entites. (Conventionally, it is the first dimension in the ordered set of dimensions - the key.) If a key family describes cross-sectional data, then for each dimension, the crossSectionalAttachDataSet, crossSectionalAttachGroup, crossSectionalAttachSection, and crossSectionalAttachObservation attributes must be given values. A value of "true" for any of these attributes indicates that the dimension may be provided a value at the indicated level within the cross-sectional structure. Note that these attributes do not need to be provided for any dimension with the isFrequencyDimension set to "true", as these dimensions are always attached only at the group level, as is time. A key family designed for cross-sectional use must be structured such that any observation's complete key can be unambiguously described by taking each dimension value from its observation level, section level, group level, and data set level, and ordered according to the sequence given in the key family. For any dimension, the id of the referenced concept
must be unique acrss the entire key family, including all dimensions, attributes and measures.
TimeDimensionType describes the special Time dimension. Any key family which will be used for time-series formats (GenericData, CompactData, and UtilityData) must include the time dimension. Any key family which uses the time dimension must also declare a frequency dimension, conventionally the first dimension in the key (the set of ordered non-time dimensions). A TextFormat element may be included for indicating the representation of time. The concept attribute must contain the concept name of the time concept. The codelist attribute may provide the value of the concept name of a codelist if needed. If a key family describes cross-sectional data, then for each dimension, the crossSectionalAttachDataSet, crossSectionalAttachGroup, crossSectionalAttachSection, and crossSectionalAttachObservation attributes must be given values. A value of "true" for any of these attributes indicates that the dimension may be provided a value at the indicated level within the cross-sectional structure. Note that these attributes do not need to be provided for any dimension with the isFrequencyDimension set to "true", as these dimensions are always attached only at the group level, as is time. A key family designed for cross-sectional use must be structured such that any observation's complete key can be unambiguously described by taking each dimension value from its observation level, section level, group level, and data set level, and ordered according to the sequence given in the key family.
GroupType declares any useful groupings of data, based on a selection of the declared (non-Time) dimensions (indicated with the DimensionRef element) which form partial keys to which attributes may be attached. The value of the DimensionRef element is the concept of the dimension - that is, the value of the dimension's concept attribute. Thus, if data is to be presented as a set of time series which vary only according to their differing frequencies, a "sibling group" would be declared, with all dimensions except the frequency dimension in it. If data is commonly grouped as a set of all countries, then a "Country Group" could be declared, with all dimensions except the country dimension forming part of the partial key. Any dimension which is not part of a group has a value which varies at the series level (for time series formats). There is no requirement to have only a single dimension ommitted from a partial key - it can be any subset of the set of ordered dimensions (that is, all dimensions except the time dimension, which may never be declared as belonging to a group partial key). All groups declared in the key family must be unique - that is, you may not have duplicate partial keys. All groups must also be given unique names (id attributes). Although it is conventional to declare dimensions in the same order as they are declared in the ordered key, there is no requirement to do so - the ordering of the values of the key are taken from the order in which the dimensions are declared. The Description element provides a human-readable description (potentially in multiple, parallel languages) of the group. Note that for cross-sectional formats, the named group mechanism is not used, but is instead replaced by a generic group which carries time and frequency values with it, and allows for any available group-level attributes to be specified if desired.
AttachmentConstraintRefType describes a reference to an attachment constraint. This includes a reference to a dataflow, metadataflow, data provider, or provision agreement plus the ID of the attachment constraint, as assigned within the constraints associated with the referenced object, in the ConstraintRef element.
ProvisionAgreementRef allows for the identification of a provision agreement. At a minimum, either the URN element - holding a valid registry URN - or the set of OragnisationSchemeAgencyID, OrganisationSchemeID, DataProviderID, DataflowAgencyID, and DataflowID must be specified. Constraint can be used to express constraints associated with the provision agreement. This type differs from the similar type in the Registry namespace package by not providing information about the datasource or constraints.
The DataProviderRef type structures a reference to a data provider. This requires that IDs be provided for an organisation scheme, its maintenance agency, and the data provider as identified in the referenced organisation scheme. The Version element may be used to specify the version of the indicated data provider. If absent, the most recent version is assumed. The URN element is used to provide the registry-specific urn as an alternate means of identification. At a minimum, either the URN element or OrgansisationSchemeID, OrganisationSchemeAgencyID, DataProviderID, and (optionally) Version must be supplied. When used in a response document of any type, the URN must always be provided. Constraints can be used to specify constraints associated with the data provider. This type differs from the similar type in the Registry namespace by not describing the datasource.
AttributeType describes the structure of attributes declared in the key family. If the codelist attribute is not used, then the attribute is uncoded. You may use the TextFormat element to specify constraints on the value of the uncoded attribute. The concept attribute contains the name of a concept. The codelist attribute supplies the id value of a codelist. The attachmentLevel attribute indicates the level to which the attribute is attached in time-series formats (GenericData, CompactData, and UtilityData formats). The assignmentStatus attribute indicates whether a value must be provided for the attribute when sending documentation along with the data. The AttachmentGroup element is included only when the attribute is attached at the Group level, to indicate which declared group or groups the attribute may be attached to. For each such group, an AttachmentGroup element should appear, with the content of the element being the name of the group. The AttachmentMeasure element is similar, indicating for cross-sectional formats which declared measure or measures the attribute attached at the observation level may be attached to. The isTimeFormat attribute indicates that the attribute represents the concept of time format (typically a mandatory series-level attribute with a codelist representation taken from ISO 8601). For key families not used to structure cross-sectional formats, this element may be ommitted. Each such element contains the name of the declared measure. The attributes crossSectionalAttachDataSet, crossSectionalAttachGroup, crossSectionalAttachSection, and crossSectionalAttachObservation indicate what the attachment level or levels are for cross-sectional data formats, and may be ommitted if the key family will not be used to structure them. A value of "true" indicates that it is permissible to provide a value for the attribute at the specified level within the structure. Note that all groups in cross-sectional formats are replaced by a generic group which has any values for time and frequency, and allows any group-level attributes to be attached to it. An attribute which is an Entity attribute has a true value for the isEntityAttribute attribute - you may have either one Entity dimension or one Entity Attribute in a key family; a non-observational time has a true value for isNonObservationalTimeAttribute; and a Count attribute has a true value for the isCountAttribute attribute. The attributes isFrequencyAttribute and isEntityAttribute are mutually exclusive - that is, only one of them may have a "true" value for any instance of the Attribute element. The definitions and limits on representation of each attribute type are as follows: Frequency attribute describes the period between observations, and is coded; Count attributes are represented by values which are sequential, incrementing numbers - representations are always of the Increment or Count type; Entity attributes describe the subject of the data set - they can be coded or represented in any other form; Non-Observational Time attributes must have a representation which contains a time; Identity attributes may be coded or uncoded, but must be represented by a scheme which refers to the identifiers of external entities. Any given instance of an attribute may only have a true value for this set of attributes, and if so may not have a true value for the isTimeFormat attribute.
Data set level
Group level
Series level
Observation level
Providing attribute value is mandatory
Providing attribute value is optional
PrimaryMeasureType describes the observation values for all presentations of the data, except those cross-sectional formats which have multiple measures (for which a set of cross-sectional measures are used instead). The concept attribute points to the unique concept represented by the measure. The PrimaryMeasure is conventionally associated with the OBS-VALUE concept. The TextFormat element allows description of the contents of the observation value. The codelist attribute references a codelist if the observation value is coded. If this attribute is used, then codelistAgencyID must contain the ID of the maintenance agency of the referenced codelist. The codelistVersion attribute may be specified - if not, then the version of the referenced codelist is assumed to be "1.0".
CrossSectionalMeasureType describes the observation values for multiple-measure cross-sectional data formats. For non-cross sectional key families, it is not necesary to specify any cross-sectional measures.The concept attribute points to the unique concept represented by the measure. The measureDimension attribute contains the concept name of the measure dimension. The code attribute contains the value of its corresponding code in the codelist used to represent the measure dimension. A CrossSectionalMeasure must be declared for each code in the codelist used to represent the measure dimension - these will replace the primary measure for multiple-measure cross-sectional data formats.The TextFormat element allows description of the contents of the observation value. The codelist attribute references a codelist if the observation value is coded. If this attribute is used, then codelistAgencyID must contain the ID of the maintenance agency of the referenced codelist. The codelistVersion attribute may be specified - if not, then the version of the referenced codelist is assumed to be "1.0".
StructureSetsType contains one or more structure sets.
StructureSetType describes the relationships between two or more key families and/or metadata structure definitions, including the mapping between category schemes and concept schemes, to provide for the mapping of representations. This can include inheritance and extension of properties, or total or partial equivalencies. It also includes mapping of concepts existing in metadata structure definitions to those used in key families, and vice-versa. A human-readable name is provided in the Name element, which may include several language-specific variants. A longer human-readable description may also be provided, in the Description element, which may also have language-specific variants provided. The Annotations element may be used to provide annotations. The StructureRefs element references all of the key families and/or metadata structure definitions included in the Structure Set - these must be provided if a StructureMap element is used, but is not required if the structure set is only used to provide codelist mappings, concept mappings, or category mappings. The StructureMap element indicates which components in the included data and metadata structures are equivalent; CodelistMap indicates which codes map to other codelists. CategorySchemeMap indicates which categories in one scheme map to those in another scheme. ConceptSchemeMap indicates which concepts in one scheme map to those in another scheme. OrganisationSchemeMap describes how one organisation scheme maps to another. The id attribute takes an id which is unique to all structure sets maintained by the agency specified in the agency attribute. version specifies a version number (by default "1.0"). The uri attribute holds a URL where a valid SDMX Structure messgae can be found which provides full details of the StructureSet, and it must be used if the isExternalReference attribute has a value of true. The urn attribute holds a valid SDMX Registry URN as described in the SDMX Registry specification. A true value in the isFinal attribute indicates that the contents of the structure set may not be changed without versioning. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
RelatedStructuresType includes references to key families (in the KeyFamilyRef element) and/or metadata structure definitions (In the MetadataStructureRef element). Any mapped CategorySchemes, ConceptSchemes, or Organisation Schemes should also be referenced. HierarchicalCodelistRef allows for HierarchicalCodelists which describe relationships between pertinent codelists to be referenced and included in the structure set - this must be used if the CodelistMap in the StructureSet refers to any hierarchical codelists.
CategorySchemeRef allows for references to specific category schemes. At a minimum, either the URN - which contains a valid Registry/Repository URN - or the rest of the child elements must be supplied.
ConceptSchemeRef allows for references to specific concept schemes. At a minimum, either the URN - which contains a valid Registry/Repository URN - or the rest of the child elements must be supplied.
OrganisationSchemeRef allows for references to specific organisation schemes. At a minimum, either the URN - which contains a valid Registry/Repository URN - or the rest of the child elements must be supplied.
HierarchicalCodelistRef allows for references to specific hierarchical codelists. At a minimum, either the URN - which contains a valid Registry/Repository URN - or the rest of the child elements must be supplied.
StructureMapType describes the structure of the mapping of components between a referenced key family or metadata structure and a target key family or metadata structure. Components include any dimension, attribute, or reported concept. The Name element is used to provide a human-readable name for the component map; the Description element is used to provide a longer human-readable description. Both of these elements may be provided in multiple, language-specific variations. The StructureMapType provides for Annotations with the Annotations element. Either a KeyFamilyRef or a MetadataStructureRef must be provided; and also a TargetKeyFamilyRef or a TargetMetadataStructureRef. A series of map components are then specified using the ComponentMap element, each of which specifies the equivalence of a concept in the referenced straucture definition to one in the target structure definition. If the isExtension attribute has a value of true, then the target structure definition inherits all properties of the referenced structure definition, and may have additional components. Note that this attribute may only be set to true if the component map has as a referenced structure definition and a target structure definition either two key families or two metadata structure definition. You cannot inherit concepts between the two type of structure definitions using this mechanism. The id attribute allows for an id to be assigned to the component map - it must be unique within its StructureSet.
CodelistMap allows the description of how the codes in a codelist are represented in a target codelist or associated hierarchical codelist. A human-readable Name is provided, and a longer, human-readable description may be provided as well, in the Name and Description elements respectively. These may be supplied in multiple, language-specific versions.CodelistRef references the codelist or hierarchical codelist being mapped; TargetCodelistRef indicates the codelist to which it will be mapped. CodeMap is the element which indicates the equivalence of codes in the referenced codelist to those in the target codelist. Any codes not mapped are assumed to lack equivalence. The CodelistMap may be annotated using the Annotations element. The id attribute is used to assign an identifier which is unique within the StructureSet for all CodelistMaps.
CodeMap describes the equivalence of the codes in the referenced codelist or hierarchical codelist indicated in the CodelistRef element of the containing CodelistMap to those in the referenced TargetCodelist in the containing CodelistMap. The CodeAlias attribute is used to assign an alias code to the equivalence for querying the structure set.
ComponentMapType describes how a component (that is, dimension, attribute, or reported concept) in a referenced metadata structure definition or key family maps to a component in a referenced "target" metadata structure definition or key family. The MapConceptRef contains the id of the concept in the metadata structure definition or key family referenced in the KeyFamilyRef or MetadataStructureRef element of the containing ComponentMap element. The MapTargetConceptRef contains the id of the concept in the metadata structure definition or key family referenced in the TargetKeyFamilyRef or TargetMetadataStructureRef element of the containing ComponentMap element. The RepresentationMapRef element contains a reference to the CodelistMap which describes how the coded representation of the referenced component maps to the coded representation of the target component. If the target component has an uncoded representation, then ToTextFormat is used to describe the un-coded representation to which the code of the referenced component should be transformed. The ToValueType element tells you whether the value, name, or description of the source value should be used in the resulting text field. The componentAlias attribute assigns a new ID to the relationship between these components. Note that of three components from different key families and/or metadata structure definitions are all equivalent, the two component maps can share a single alias. Note also that for metadata concepts which are represented not by codelists but rather by other types of item schemes (OrganisationSchemes or CategorySchemes), these can also be referenced using the RepresentationMapRef element. The preferredLanguage attribute specifies the language to use when translating coded values into their names or descriptions, if available, in the same form as xml:lang.
ToValueTypeType provides an enumeration of available text-equivalents for translation of coded values into textual formats.
Code or other tokenized value, as provided in the representation scheme.
The human-readable name of the Value, as provided in the representation scheme.
The human-readable description of the Value, as provided in the representation scheme.
RepresentationMapRefType describes the structure of a reference to a codelist, category scheme, or organisation scheme map. RepresentationMapAgencyID takes the id value of the maintenance agency of the codelist, category scheme, or organisation scheme map; RepresentationMapID takes the id attribute value of the codelist, category scheme, or organisation scheme map.
RepresentationTypeType provides an enumeration of representation scheme types useful for the mapping of reference metadata concepts to one another.
Codelist
CategoryScheme
OrganisationScheme
CategorySchemeMap provides for the mapping of categories in one scheme against those in another. It requires a human-readable Name, and can have a longer human-readable Description, both of which can be supplied in multiple, parallel-language form. It may be annotated using Annotations. The id attribute carries a unique ID for CategorySchemeMaps within the StructureSet. CategorySchemeRef identifies the source CategoryScheme; TargetCategorySchemeRef identifies the target CategoryScheme.
CategoryMap allows for the mapping of a category in one scheme against a category in another, target scheme. The categoryAlias attribute allows for an alias to be assigned to the mapping for searching across the set of mapped categories. Note that the Category IDs are recursive, and can therefore describe a path through a category scheme.
ConceptSchemeMap provides for the mapping of concepts in one scheme against those in another. It requires a human-readable Name, and can have a longer human-readable Description, both of which can be supplied in multiple, parallel-language form. It may be annotated using Annotations. The id attribute carries a unique ID for ConceptSchemeMaps within the StructureSet. ConceptSchemeRef identifies the source ConceptScheme; TargetConceptSchemeRef identifies the target ConceptScheme.
ConceptMap allows for the mapping of a concept in one scheme against a concept in another, target scheme. The conceptAlias attribute allows for an alias to be assigned to the mapping for searching across the set of mapped concepts.
OrganisationSchemeMap provides for the mapping of Organisations in one scheme against those in another. It requires a human-readable Name, and can have a longer human-readable Description, both of which can be supplied in multiple, parallel-language form. It may be annotated using Annotations. The id attribute carries a unique ID for OrganisationSchemeMaps within the StructureSet. OrganisationSchemeRef identifies the source OrganisationScheme; TargetOrganisationSchemeRef identifies the target OrganisationScheme.
OrganisationMap allows for the mapping of an organisation in one scheme against an organisation in another, target scheme. The organisationAlias attribute allows for an alias to be assigned to the mapping for searching across the set of mapped organisations.
ReportingTaxonomiesType holds on or more ReportingTaxonomy elements.
ReportingTaxonomyType groups data flows and/or metadata flows for the purposes of assembling "reports" made up of data from disparate sources. It is a maintainable object, and thus has a mandatory human-readable Name and optional Description containing a longer human-readable description. Annotations may be included. All of these fields may be provided in multiple, parallel languages. The id attribute assignes a unique ID to the Reporting Taxonomy, version provides a version number, uri contains a URL where the SDMX-ML expression of the Reporting taxonomy can be found, and must be included if the isExternalReference attribute has a value of true. The urn attribute holds the value of a valid SDMX Registry URN as per the SDMX Registry specification. The isExternalReference attribute, if set to true, indicates that the uri attribute points to an external location for the ReportingTaxonomy, with only the id, Name element, and version supplied in addition. The agencyID attribute holds the ID of the Reporting Taxonomies' maintenance agency. Also, if the Reporting Taxonomy is final, the isFinal attribute must`have a value of true - otherwise, it will be assumed to be non-final. (All production versions must be made final - that is, unchangeable without versioning.) The sub-element Category may be used to group dataflows and metadataflows into useful sub-packages. DataflowRef and MetadataFlowRef are references to the flows which make up the reporting taxonomy at the top level. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
The MetadataflowRef type structures a reference to a metadataflow definition. This requires that ID are provided for a pre-existing Agency and Metadataflow Definition in the registry. The Version element may be used to specify the version of the indicated dataflow. If absent, the most recent version is assumed. The URN element is used to provide the registry-specific URN as an alternate means of identification. When used in a response document of any type, the URN must always be provided. At a minimum, either the URN element or AgencyID, MetadataflowID, and (optionally) version must be supplied. Datasource may be used to specify a datasource. Constraint can be used to provide constraints associated with the metadataflow. Note that this is similar, but not identical to the MetadataflowRefType found in the SDMX-ML registry namespace package - it lacks references to the datasource and the constraints.
The DataflowRef type structures a reference to a dataflow definition. This requires that ID are provided for a pre-existing Agency and Dataflow Definition in the registry. The Version element may be used to specify the version of the indicated dataflow. If absent, the most recent version is assumed. The URN element is used to provide the registry-specific URN as an alternate means of identification. At a minimum, either the URN element or AgencyID, DataflowID, and (optionally) version must be supplied. When used in a response document of any type, the URN must always be provided. Datasource may be used to specify a datasource. Constraints can be used to specify constraints associated with the dataflow. Note that this is similar, but not identical to the DataflowRefType found in the SDMX-ML registry namespace package - it lacks references to the datasource and the constraints.
ProcessesType describes a list of Processes.
ProcessType generically describes a statistical process. In this version of the SDMX Technical Specifications, it is not meant to support process automation, but serves as a description of how processes occur. The primary use for this structural mechanism is the attachment of reference metadata regarding statistical processing. A process has a human-readable Name, which may be provided in multiple, parallel-language versions. It also has an optional human-readable Description, which also may be provided with multiple, parallel-language versions. The Annotations element allows for it to be annotated. The id attribute takes a unique id within the set of processes maintained by the agency identified in the agencyID attribute. The version attribute indicated the version of teh process description. The uri value is a URL where a complete description of the Process may be found; the urn attribute takes the valid registry URN of the Process, as described in the SDMX Registry Specification. If isFinal is set to true, the process description cannot be changed without versioning. If isExternalReference is true, then only the id, agency, Name, and uri (or URN) need be supplied - all other fields are assumed to be found in a valid SDMX Structure message found at the uri attribute location. The validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version.
ProcessStepType describes a single step in a statistical process. ProcessSteps may be recursive. The Input element specifies the type of object(s) which serve as inputs to the process; the Output element specifies the type of objects which are the result of the process. Computation elements describe the computations involved in the process, in any form desired by the user (these are informational rather than machine-actionable), and so may be supplied in multiple, parallel-language versions. Transitions describe the process steps to which a process is connected - that is, which processes happen next. The process step maust be given a Name, and may be given a Description. These are human-readable, and may be supplied in multiple, parallel-language versions. Annotations may be supplied. The id attribute takes the unique identifier of the process step within the parent process.
TransitionType describes the Condition and next step in a transition. The Condition text is informational, and may be supplied in multiple, parallel-language form. The TargetStep holds the id of the next step in the process if the condition is met.