Difference between revisions of "REST API Overview"
(→Scope of the SDMX API) |
(→Scope of the SDMX REST API) |
||
Line 15: | Line 15: | ||
* For structural metadata, it is possible to retrieve a minimal version of the artefact, for the sake of efficiency (for example, to retrieve all code lists – names, ids, etc – without the codes). | * For structural metadata, it is possible to retrieve a minimal version of the artefact, for the sake of efficiency (for example, to retrieve all code lists – names, ids, etc – without the codes). | ||
* A distinction should be established between the elements that allow identifying the resource to be retrieved and the elements that give additional information about, or allow to further filter, the desired results. Elements belonging to the 1st category are specified in the path part of the URL while elements belonging to the 2nd category are specified in the query string part of the URL. | * A distinction should be established between the elements that allow identifying the resource to be retrieved and the elements that give additional information about, or allow to further filter, the desired results. Elements belonging to the 1st category are specified in the path part of the URL while elements belonging to the 2nd category are specified in the query string part of the URL. | ||
+ | |||
+ | Fusion Metadata Registry is primarily concerned with structural metadata so implements a subset of the SDMX RESTful API specification. | ||
+ | {| class="wikitable" | ||
+ | |- | ||
+ | ! REST API Function !! Implemented | ||
+ | |- | ||
+ | | Structure Queries || YES | ||
+ | |- | ||
+ | | Data Queries || NO | ||
+ | |- | ||
+ | | Schema Queries || YES | ||
+ | |- | ||
+ | | Data Availability || NO | ||
+ | |} | ||
== Structural Metadata Queries == | == Structural Metadata Queries == |
Revision as of 07:39, 20 January 2021
Contents
SDMX Standard REST API
Scope of the SDMX REST API
The RESTful API focuses on simplicity. The aim is not to replicate the full semantic richness of the SDMX-ML Query message but to make it simple to perform a limited set of standard queries. Also, in contrast to other parts of the SDMX specification, the RESTful API focuses solely on data retrieval (via HTTP GET). More specifically, the API allows:
- To retrieve structural metadata, using a combination of id, agencyID and version number.
- To retrieve statistical data or reference metadata using keys (with options for wildcarding and support for the OR operator), data or metadata flows and data or metadata providers.
- To further refine queries for statistical data or reference metadata using time information (start period and end period).
- To retrieve updates and revisions only.
- To return the results of a query in various formats. The desired format and version of the returned message will be specified using HTTP Content Negotiation (and the HTTP Accept request header).
- For structural metadata, it is possible to instruct the web service to resolve references (for instance, when querying for data structure definitions, it is possible to also retrieve the concepts and code lists used in the returned data structure definitions), as well as artefacts that use the matching artefact (for example, to retrieve the dataflows that use a matching data structure definition).
- For structural metadata, it is possible to retrieve a minimal version of the artefact, for the sake of efficiency (for example, to retrieve all code lists – names, ids, etc – without the codes).
- A distinction should be established between the elements that allow identifying the resource to be retrieved and the elements that give additional information about, or allow to further filter, the desired results. Elements belonging to the 1st category are specified in the path part of the URL while elements belonging to the 2nd category are specified in the query string part of the URL.
Fusion Metadata Registry is primarily concerned with structural metadata so implements a subset of the SDMX RESTful API specification.
REST API Function | Implemented |
---|---|
Structure Queries | YES |
Data Queries | NO |
Schema Queries | YES |
Data Availability | NO |
Structural Metadata Queries
Resources
The following resources are defined:
- datastructure (This has been shortened from DataStructureDefinition to allow for shorter URLs)
- metadatastructure (This has been shortened from MetadataStructureDefinition to allow for shorter URLs)
- categoryscheme
- conceptscheme
- codelist
- hierarchicalcodelist
- organisationscheme (The organisationscheme resource can be used whenever the role played by the organisation schemes is not known/relevant)
- agencyscheme (For 3 of the subtypes of OrganisationScheme, the id and version parameters have fixed values. See Section 03 of the SDMX information model document for additional information)
- dataproviderscheme
- dataconsumerscheme
- organisationunitscheme
- dataflow
- metadataflow
- reportingtaxonomy
- provisionagreement
- structureset
- process
- categorisation
- contentconstraint
- actualconstraint (a type of contentconstraint stating what data are actually present)
- allowedconstraint (a type of contentconstraint defining what data are allowed)
- attachmentconstraint
- transformationscheme
- rulesetscheme
- userdefinedoperatorscheme
- customtypescheme
- namepersonalisationscheme
- vtlmappingscheme
- structure (This type can be used to retrieve any type of structural metadata matching the supplied parameters)
Parameters
Parameters used for identifying a resource
The following parameters are used for identifying resources:
Parameter | Type | Description |
---|---|---|
agencyID | A string compliant with the SDMX common:NCNameIDType | The agency maintaining the artefact to be returned. It is possible to set more than one agency, using + as separator (e.g. BIS+ECB).
|
resourceID | A string compliant with the SDMX common:IDType | The id of the artefact to be returned. It is possible to set more than one id, using + as separator (e.g. CL_FREQ+CL_CONF_STATUS).
|
version | A string compliant with the SDMX common:VersionType | The version of the artefact to be returned. It is possible to set more than one version, using + as separator (e.g. 1.0+2.1).
|
The parameters mentioned above are specified using the following syntax:
protocol://ws-entry-point/resource/agencyID/resourceID/version
Furthermore, some keywords may be used:
Keywords | Scope | Description |
---|---|---|
all | agencyID | Returns artefacts maintained by any maintenance agency |
all | resourceID | Returns all resources of the type defined by the resource parameter |
all | version | Returns all versions of the resource |
latest | version | Returns the latest version in production of the resource |
As all
is a reserved keyword in the SDMX RESTful API, it is recommended not to use it as an identifier for agencies, resources or a specific version.
The following rules apply:
- If no version is specified, the version currently used in production should be returned. It is therefore equivalent to using the keyword
latest
. - If no agencyID is specified, the matching artefacts maintained by any maintenance agency should be returned. It is therefore equivalent to using the keyword
all
. This would potentially return more than one artefact, if different agencies give the same identifier to a resource (for example, http://ws-entry-point/codelist/all/CL_FREQ, could return more than one codelist if more than one agency is maintaining a codelist with id "CL_FREQ"). - If no resourceID is specified, all matching artefacts (according to the other criteria used) should be returned. It's is therefore equivalent to using the keyword
all
. - If no parameters are specified, the latest version of all resources of the type identified by the resource parameter, maintained by any maintenance agency should be returned.
Additional parameter used for identifying a resource, for item scheme types
SDMX uses the item scheme pattern to model SDMX collections of items. These are:
- categoryscheme
- conceptscheme
- codelist
- organisationscheme
- agencyscheme
- dataproviderscheme
- dataconsumerscheme
- organisationunitscheme
- reportingtaxonomy
- transformationscheme
- rulesetscheme
- userdefinedoperatorscheme
- customtypescheme
- namepersonalisationscheme
- vtlmappingscheme
Although it is not following the item scheme pattern, hierarchicalcodelist is also a collection, i.e. a collection of hierarchies.
For these collections (those following the item scheme pattern or the hierarchicalcodelist), it is possible to use a 4th parameter for identifying a resource. The rules for the 3 other parameters, as defined in the section above, remain valid.
Parameter | Type | Description |
---|---|---|
itemID | A string compliant with the SDMX common:NestedNCNameIDType for conceptscheme and agencyscheme, SDMX common:IDType for hierarchicalcodelist or with the SDMX common:NestedIDType in all other cases | The id of the item to be returned. It is possible to set more than one id, using + as separator (e.g. A+Q+M).
|
This 4th parameter is used as follows:
protocol://ws-entry-point/resource/agencyID/resourceID/version/itemID
Furthermore, a keyword may be used:
Keyword | Scope | Description |
---|---|---|
all | itemID | Returns all items belonging to the item scheme |
The following rules apply:
- If no itemID is specified, all the items belonging to the item scheme should be returned. It is therefore equivalent to using the keyword
all
. - If
itemID
is set and is a top-level id (e.g.: Code A (Annual) in the Frequency Codelist), and such an item exists in the matching item scheme, the item scheme returned should contain only the matching item and itsisPartial
parameter should be set totrue
. - If
itemID
is set and is a nested id (e.g.: Category A.1.1, belonging to Category A.1, belonging to Category A in a Category Scheme), and such an item exists in the matching item scheme, the item scheme returned should contain the matching item and its ancestors, and itsisPartial
parameter should be set totrue
.
Parameters used to further describe the desired results
The following parameters are used to further describe the desired results, once the resource has been identified. As mentioned in 3.2, these parameters appear in the query string part of the URL.
Parameter | Type | Description | Default |
---|---|---|---|
detail | String | This attribute specifies the desired amount of information to be returned. For example, it is possible to instruct the web service to return only basic information about the maintainable artefact (i.e.: id, agency id, version and name). Most notably, items of item schemes will not be returned (for example, it will not return the codes in a code list query). Possible values are: allstubs (all artefacts should be returned as stubs, containing only identification information, as well as the artefacts' name), referencestubs (referenced artefacts should be returned as stubs, containing only identification information, as well as the artefacts' name), referencepartial (referenced item schemes should only include items used by the artefact to be returned. For example, a concept scheme would only contain the concepts used in a DSD, and its isPartial flag would be set to true . Likewise, if a dataflow has been constrained, then the codelists referenced by the DSD referenced by the dataflow should only contain the codes allowed by the content constraint), allcompletestubs (all artefacts should be returned as complete stubs, containing identification information, the artefacts' name, description, annotations and isFinal information), referencecompletestubs (referenced artefacts should be returned as complete stubs, containing identification information, the artefacts' name, description, annotations and isFinal information) and full (all available information for all artefacts should be returned).
|
full |
references | String | This attribute instructs the web service to return (or not) the artefacts referenced by the artefact to be returned (for example, the code lists and concepts used by the data structure definition matching the query), as well as the artefacts that use the matching artefact (for example, the dataflows that use the data structure definition matching the query). Possible values are: none (no references will be returned), parents (the artefacts that use the artefact matching the query), parentsandsiblings (the artefacts that use the artefact matching the query, as well as the artefacts referenced by these artefacts), children (artefacts referenced by the artefact to be returned), descendants (references of references, up to any level, will also be returned), all (the combination of parentsandsiblings and descendants). In addition, a concrete type of resource may also be used (for example, references=codelist).
|
none |
Applicability and meaning of references attribute
The table below lists the 1st level artefacts (one level up, one level down) that will be returned if the references parameter is set to all
. Artefacts referenced by the matching artefact are displayed in regular style, while the artefacts that reference the matching artefact are displayed in Italic.
Maintainable artefact | Artefacts returned |
---|---|
AgencyScheme | Categorisation, Process, MetadataStructureDefinition, StructureSet |
Categorisation | All |
CategoryScheme | Categorisations, Process, StructureSet |
Codelist | Categorisation, Process, HierarchicalCodelist, ConceptScheme, DataStructureDefinition, MetadataStructureDefinition, StructureSet, VtlMappingScheme |
ConceptScheme | Categorisation, Process, Codelist, DataStructureDefinition, MetadataStructureDefinition, StructureSet, VtlMappingScheme |
Constraint | Categorisation, Process, DataProviderScheme, DataStructureDefinition, Dataflow, MetadataStructureDefinition, Metadataflow, ProvisionAgreement |
DataConsumerScheme | Categorisation, Process, MetadataStructureDefinition, StructureSet |
Dataflow | Categorisation, Process, Constraint, DataStructureDefinition, ProvisionAgreement, ReportingTaxonomy, StructureSet, VtlMappingScheme |
DataProviderScheme | Categorisation, Process, Constraint, ProvisionAgreement, MetadataStructureDefinition, StructureSet |
DataStructureDefinition | Categorisation, Process, Codelist, ConceptScheme, Constraint, Dataflow, StructureSet |
HierarchicalCodelist | Categorisation, Process, Codelist, StructureSet |
Metadataflow | Categorisation, Process, Constraint, MetadataStructureDefinition, ProvisionAgreement, ReportingTaxonomy, StructureSet |
MetadataStructureDefinition | Categorisation, Process, ConceptScheme, Codelist, DataProviderScheme, DataConsumerScheme, AgencyScheme, OrganisationUnitScheme, Constraint, Metadataflow, StructureSet |
OrganisationUnitScheme | Categorisation, Process, Constraint, MetadataStructureDefinition, StructureSet |
Process | All |
ProvisionAgreement | Categorisation, Process, DataProviderScheme, Dataflow, Metadataflow, Constraint |
ReportingTaxonomy | Categorisation, Process, Dataflow, Metadataflow, StructureSet |
StructureSet | Categorisation, Process, DataStructureDefinition, MetadataStructureDefinition, CategoryScheme, DataProviderScheme, DataConsumerScheme, AgencyScheme, OrganisationUnitScheme, ConceptScheme, Codelist, ReportingTaxonomy, HierarchicalCodelist, Dataflow, Metadataflow |
CustomTypeScheme | AgencyScheme, Categorisation, TranformationScheme |
NamePersonalisationScheme | AgencyScheme, Categorisation, TranformationScheme |
RulesetScheme | AgencyScheme, Categorisation, TranformationScheme, VtlMappingScheme |
TranformationScheme | AgencyScheme, Categorisation, CustomTypeScheme, NamePersonalisationScheme, RulesetScheme, UserDefinedOperatorScheme, VtlMappingScheme |
UserDefinedOperatorScheme | AgencyScheme, Categorisation, TranformationScheme, VtlMappingScheme |
VtlMappingScheme | AgencyScheme, Categorisation, Codelist, ConceptScheme, Dataflow, RulesetScheme, TranformationScheme, UserDefinedOperatorScheme |
Examples
To retrieve version 1.0 of the DSD with id ECB_EXR1 maintained by the ECB, as well as the code lists and the concepts used in the DSD:
http://ws-entry-point/datastructure/ECB/ECB_EXR1/1.0?references=children&detail=referencepartial
To retrieve the latest version in production of the DSD with id ECB_EXR1 maintained by the ECB, without the code lists and concepts of the DSD:
http://ws-entry-point/datastructure/ECB/ECB_EXR1
To retrieve all DSDs maintained by the ECB, as well as the dataflows using these DSDs:
http://ws-entry-point/datastructure/ECB?references=dataflow
To retrieve the latest version in production of all code lists maintained by all maintenance agencies, but without the codes:
http://ws-entry-point/codelist?detail=allstubs
To retrieve, as stubs, the latest version in production of all maintainable artefacts maintained by the ECB:
http://ws-entry-point/structure/ECB?detail=allstubs
To retrieve the category PRICES of the DOMAINS category scheme maintained by the ECB, as well as the categorisations referencing that category:
http://ws-entry-point/categoryscheme/ECB/DOMAINS/latest/PRICES?references=categorisation
To retrieve the latest version of the CL_FREQ codelists maintained by the BIS or the ECB: http://ws-entry-point/codelist/BIS+ECB/CL_FREQ
Schema queries
Resources
The following resource is defined:
- schema
This resource allows a client to ask a service to return a schema, i.e. a document which defines data validity within a certain context. The service must take into account the constraints that apply within that context (DSD or MSD, dataflow or metadataflow, or provision agreement).
This is typically used for validation purposes but it may also be used for communication purposes, i.e. as a way to inform providers about the data they are expected to report.
Parameters
Parameters used for identifying a resource
The following parameters are used for identifying resources:
Parameter | Type | Description |
---|---|---|
context | One of the following: datastructure , metadatastructure , dataflow , metadataflow , provisionagreement
|
The value of this parameter determines the constraints that need to be taken into account, when generating the schema. If datastructure or metadatastructure is used, constraints attached to the DSD or MSD must be applied when generating the schema. If dataflow or metadataflow is used, constraints attached to the dataflow or metadataflow and to the DSD or MSD used in the dataflow or metadataflow must be applied when generating the schema. If provisionagreement is used, constraints attached to the provision agreement, as well as to the dataflow or metadafalow used in the agreement and the DSD or MSD used in the dataflow or metadataflow must be applied when generating the schema. |
agencyID | A string compliant with the SDMX common:NCNameIDType | The agency maintaining the artefact used to generate the schema to be returned. |
resourceID | A string compliant with the SDMX common:IDType | The id of the artefact used to generate the schema to be returned. |
version | A string compliant with the SDMX common:VersionType | The version of the artefact used to generate the schema to be returned. |
The parameters mentioned above are specified using the following syntax:
protocol:// ws-entry-point/schema/context/agencyID/resourceID/version
Furthermore, a keyword may be used:
Keyword | Scope | Description |
---|---|---|
latest | version | Returns the latest version in production of the resource |
As the query for schema must match one artefact only, the keyword all
is not supported for agencyId and resourceId.
The following rules apply:
- If no version attribute is specified, the version currently used in production should be returned. It is therefore equivalent to using the keyword
latest
.
Parameters used to further describe the desired results
The following parameters are used to further describe the desired results, once the resource has been identified:
Parameter | Type | Description |
---|---|---|
dimensionAtObservation | A string compliant with the SDMX common:NCNameIDType | The ID of the dimension to be attached at the observation level. |
explicitMeasure | Boolean | For cross-sectional data validation, indicates whether observations are strongly typed (defaults to false ).
|
Using an SDMX format for the response
By default, a schema query will return an XML schema (i.e. an xsd
file). However, it is also possible to get the response in one of the SDMX Structure formats. In that case, the response should only include the following types of artefact: data structures, codelists, concept schemes and agency schemes. The various item schemes must only contain the following:
- For codelists, the codes that are allowed after applying the constraints up to the specified context;
- For concept schemes, the concepts that are used by the data structure;
- For agency schemes, the agencies maintaining artefacts that are part of the response.
Examples
To retrieve the schema for data supplied within the context of version 1.0 of the provision agreement EXR_WEB maintained by the ECB:
http://ws-entry-point/schema/provisionagreement/ECB/EXR_WEB/1.0/
In this case, the schema returned by the service must take into account the constraints attached to the provision agreement, the dataflow used in the provisionagreement and the data structure definition used in the dataflow.
Structure Submission
Fusion Metadata Registry Extended REST API
Data Validation
Entry Point | /ws/public/data/validate |
Access | Public (default). Configurable to Private |
Http Method | POST |
Accepts | CSV, XLSX, SDMX-ML, SDMX-EDI (any format for which there is a Data Reader) |
Compression | Zip files supported, if loading from URL gzip responses supported |
Content-Type | 1. multipart/form-data (if attaching file) – the attached file must be in field name of uploadFile 2. application/text or application/xml (if submitting data in the body of the POST) |
Response Format | application/json |
Response Statuses | 200 - Validation could be performed 400 - Validation could not be performed (either an unreadable dataset, or unresolvable reference to a required structure) 401 - Unauthorized (if access has been restricted) 500 - Server Error |
HTTP Headers
HTTP Header | Purpose | Allowed Values |
---|---|---|
Data-Format | Used to inform the server when the data is in CSV format. | csv;delimiter=[delimiter]
Where [delimiter] is either:
|
Structure | (optional) Provides the structure to validate the data against. This information may be present in the header of the dataset, if provided this value will override the value in the dataset. Fusion Registry v10.4.7 onwards accepts a comma separated list of URNs if multiple datasets exist in the loaded file, however if multiple URNs are provided, URN must be of a Dataflow or Provision Agreement and the datasets must identify at a minimum the Data Structure that is needed to read the file. |
Valid SDMX URN for Provision Agreement, Dataflow, or Data Structure Definition |
Inc-Metrics (Since v9.8) |
Optional. Includes metrics on the validation. This will add extra detail to the validation report. |
Boolean (true/false) |
Inc-Valid (Since v9.8) |
Optional. Instructs the service to include a dataset with all the valid series and observations in the response. As the result will contain a separate file for the dataset, the response format will be set to either multipart/mixed message with a boundary per file, or if the Zip header is set to true, the output will be a single zip file. The file is called ValidData with the file extension based on the output format. |
Boolean (true/false) |
Inc-Invalid (Since v9.8) |
Optional. Instructs the service to include a dataset with all the invalid series and observations in the response. As the result will contain a separate file for the dataset, the response format will be set to either multipart/mixed message with a boundary per file, or if the Zip header is set to true, the output will be a single zip file. The file is called InvalidData with the file extension based on the output format. |
Boolean (true/false) |
Accept (Since v9.8) |
Optional. Instructs the service which data output format to output the valid or invalid datasets in. This Header is only used if Inc-Valid or Inc-Invalid are set to true. |
See Accept Formats |
Zip (Since v9.8) |
Optional. Compresses the output as a zip file. If used in conjunction with Inc-Valid or Inc-Invalid the zip will contain multiple files. | Boolean (true/false) |
Prior-Data-Dependent (Since v9.8) |
Optional. This allows data to be validated under the assumption that other data will provide missing information. If this value is set to true, particular data validators will not be used when validating the data. These validators are "Mandatory Observations" and "Valid Calculations". Default value is false. |
Boolean (true/false) |
Response
The validation output contains both human readable error descriptions, as well as machine processible locations of the errors within the dataset. The location in the dataset is described as a key or observation locator in the format; A:UK:M:2008 – where each component relates to the Dimension value, separated by a colon. If the error position is observation, the last part of the key is the observation time period.
Since Fusion Registry 10.5.4, error code values are output, which provide a unique code for each type of error. For a list of the error codes, refer to error codes.
There are 3 types of output that can be produced which share a common structure: unable to parse input(returns HTTP 400); able to parse input but references invalid data structure (returns HTTP 200); parsed input and returns output, which may have validation errors (return HTTPS 200). Below are examples of each:
Valid Dataset
{ "Meta": { "RequestTime": 1564410081711, "Duration": 43 }, "FileFormat": "Structure Specific (Compact) v2.1", "Prepared": "2019-07-29T10:23:01", "SenderId": "FR_DEMO", "DataSetId": null, "Status": "Complete", "Errors": false, "Datasets": [ { "DSD": "urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=OECD:HIGH_AGLINK_2011(1.0)", "Dataflow": "urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=OECD:AGRIC_OUTLOOK_2011_2020(1.0)", "DataProvider": "urn:sdmx:org.sdmx.infomodel.base.DataProvider=METATECH:DATA_PROVIDERS(1.0).METATECH", "ProvisionAgreement": "urn:sdmx:org.sdmx.infomodel.registry.ProvisionAgreement=OECD:OECD_AGRIC_OUTLOOK(1.0)", "KeysCount": 2, "ObsCount": 62, "GroupsCount": 0, "Errors": false "ReportedPeriods": { "A": { "Name": "Annual", "StartPeriod": "1990", "EndPeriod": "2020" } }, } ], "PreventsConversion": false, "PreventsPublication": false }
Dataset with Errors
{ "Meta": { "RequestTime": 1564401209760, "Duration": 34 }, "InvalidData": { "Datasets": [ { "Structure": "urn:sdmx:org.sdmx.infomodel.registry.ProvisionAgreement=OECD:OECD_AGRIC_OUTLOOK(1.0)", "Series": 2, "Observations": 61, "Groups": 0 } ] }, "ValidData": { "Datasets": [ { "Structure": "urn:sdmx:org.sdmx.infomodel.registry.ProvisionAgreement=OECD:OECD_AGRIC_OUTLOOK(1.0)", "Series": 2, "Observations": 32, "Groups": 0 } ] }, "FileFormat": "Structure Specific (Compact) v2.1", "Prepared": "2019-07-29T10:23:01", "SenderId": "FR_DEMO", "DataSetId": null, "Status": "Complete", "Errors": true, "Datasets": [ { "DSD": "urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=OECD:HIGH_AGLINK_2011(1.0)", "Dataflow": "urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=OECD:AGRIC_OUTLOOK_2011_2020(1.0)", "DataProvider": "urn:sdmx:org.sdmx.infomodel.base.DataProvider=METATECH:DATA_PROVIDERS(1.0).METATECH", "ProvisionAgreement": "urn:sdmx:org.sdmx.infomodel.registry.ProvisionAgreement=OECD:OECD_AGRIC_OUTLOOK(1.0)", "KeysCount": 3, "ObsCount": 93, "GroupsCount": 0, "ReportedPeriods": { "A": { "Name": "Annual", "StartPeriod": "1990", "EndPeriod": "2020" } }, "Errors": true, "ValidationReport": [ { "Type": "Constraint", "Errors": [ { "ErrorCode": "REG-201-250", "Message": "Disallowed Dimension Value: REF_AREA=AFR", "Dataset": 0, "ComponentId": " REF_AREA ", "ReportedValue": "AFR", "Position": "Series", "Keys": ["AFR:BT:AA"] } ] }, { "Type": "Representation", "Errors": [ { "ErrorCode": "REG-201-200", "Message": "Dimension 'VARIABLE' is reporting value 'AA' which is not a valid representation in referenced Codelist 'OECD:CL_HIGH_AGLINK_2011_VARIABLE(1.0)'", "Dataset": 0, "Position": "Series", "ComponentId": "VARIABLE", "ReportedValue": "AA", "Keys": ["AFR:BT:AA"] }, { "ErrorCode": "REG-201-201", "Message": "Error in Primary Measure 'OBS_VALUE': Reported value 'XXX' is not of expected type 'Double'", "Dataset": 0, "ComponentId": " OBS_VALUE", "ReportedValue": "XXX", "Position": "Observation", "Keys": ["AFR:BT:IM:2010"] } ] }, { "Type": "FormatSpecific", "Errors": [ { "Message": "Unexpected attribute 'ASD' for element 'StructureSpecificData/DataSet/Series/Obs'", "Dataset": 0, "Position": "Dataset" } ] } ] } ], "PreventsConversion": false, "PreventsPublication": true }
Note the first three elements ‘Meta’, ‘InvalidData’, ‘ValidData’, there are present in the report if Inc-Metrics is set to true. Inc-valid and Inc-Invalid set to true enables the report to know the metrics for the invalid and valid data.
Note also each Error has a Type, this is the category of error which caused the validator to fail. For a list of all validators see the following section on Validators. The Error Position is either set to Dataset, Series, Observation, or Group.
PreventsConversion and PreventsPublication is an indication on the severity of the error. These settings on which errors prevent conversion and publication can be set in the Fusion Registry by the administrator of the system.
Dataset with an Unresolvable Datset Reference
{ "FileFormat": "Generic v2.1", "MimeType": "application/xml", "Status": "InvalidRef", "Errors": true, "Datasets": [{"Dataflow": "urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=BIS:INVALID_DATAFLOW(1.0)"}] }
Errors has a value of true, the Status states InvalidRef, and the Datasets provides the reported reference which could not be resolved
Dataset which could not be read
{ "Status": "Error", "Errors": true, "Error": "Unexpected '<' character in element (missing closing '>'?)\r\n at [row,col {unknown-source}]: [17,3]" }
This error will be reported when the Fusion Registry is unable to determine what type of data the dataset is, so is unable to process the dataset for validation