You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: v2_1/ws/rest/docs/4_3_structural_queries.md
+22-4Lines changed: 22 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,6 +26,12 @@ The following resources are defined:
26
26
- actualconstraint (a type of contentconstraint stating what data are actually present)
27
27
- allowedconstraint (a type of contentconstraint defining what data are allowed)
28
28
- attachmentconstraint
29
+
- transformationscheme
30
+
- rulesetscheme
31
+
- userdefinedoperatorscheme
32
+
- customtypescheme
33
+
- namepersonalisationscheme
34
+
- vtlmappingscheme
29
35
- structure (This type can be used to retrieve any type of structural metadata matching the supplied parameters)
30
36
31
37
@@ -77,6 +83,12 @@ SDMX uses the *item scheme* pattern to model SDMX collections of items. These ar
77
83
- dataconsumerscheme
78
84
- organisationunitscheme
79
85
- reportingtaxonomy
86
+
- transformationscheme
87
+
- rulesetscheme
88
+
- userdefinedoperatorscheme
89
+
- customtypescheme
90
+
- namepersonalisationscheme
91
+
- vtlmappingscheme
80
92
81
93
Although it is not following the *item scheme* pattern, *hierarchicalcodelist* is also a collection, i.e. a collection of hierarchies.
82
94
@@ -109,7 +121,7 @@ The following parameters are used to further describe the desired results, once
109
121
110
122
Parameter | Type | Description | Default
111
123
--- | --- | --- | ---
112
-
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`), `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**
124
+
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**
113
125
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**
114
126
115
127
#### Applicability and meaning of references attribute
@@ -121,11 +133,11 @@ Maintainable artefact | Artefacts returned
Copy file name to clipboardExpand all lines: v2_1/ws/rest/docs/4_5_schema_queries.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,8 +7,9 @@ The following resource is defined:
7
7
8
8
- schema
9
9
10
-
This resource allows a client to ask a service to return an XML schema, which defines data (or reference metadata) 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).
10
+
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).
11
11
12
+
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.
12
13
13
14
### Parameters
14
15
@@ -48,6 +49,14 @@ Parameter | Type | Description
48
49
dimensionAtObservation | A string compliant with the SDMX *common:NCNameIDType* | The ID of the dimension to be attached at the observation level.
49
50
explicitMeasure | *Boolean* | For cross-sectional data validation, indicates whether observations are strongly typed (defaults to `false`).
50
51
52
+
### Using an SDMX format for the response
53
+
54
+
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:
55
+
56
+
- For codelists, the codes that are allowed after applying the constraints up to the specified *context*;
57
+
- For concept schemes, the concepts that are used by the data structure;
58
+
- For agency schemes, the agencies maintaining artefacts that are part of the response.
59
+
51
60
### Examples
52
61
53
62
* To retrieve the schema for data supplied within the context of version 1.0 of the provision agreement EXR_WEB maintained by the ECB:
Copy file name to clipboardExpand all lines: v2_1/ws/rest/docs/4_6_conneg.md
+41-17Lines changed: 41 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,23 +20,43 @@ A few examples are listed below
20
20
21
21
In case the client does not specify the desired format and version of the response message, or only specifies the generic application/xml format, the SDMX RESTful web service should return:
22
22
23
-
- The most recent version, that the service supports, of the SDMX-ML Structure format for structural metadata queries;
24
-
- The most recent version, that the service supports, of the SDMX-ML Generic Data format for data queries;
25
-
- The most recent version, that the service supports, of the SDMX-ML Generic Metadata format for metadata queries.
26
-
27
-
The list below indicates the valid formats for SDMX RESTful web services, compliant with version 2.1 of the SDMX standard:
- The most recent version, that the service supports, of the SDMX-ML Structure format for **structural metadata** queries;
24
+
- The most recent version, that the service supports, of the SDMX-ML Generic Data format for **data** queries;
25
+
- The most recent version, that the service supports, of the SDMX-ML Generic Metadata format for **reference metadata** queries;
26
+
- An XML schema (i.e. an `xsd` file) for **schema** queries.
27
+
- The most recent version, that the service supports, of the SDMX-ML Structure format for **data availability** queries;
28
+
29
+
The list below indicates the valid formats for SDMX RESTful web services, compliant with version 2.1 of the SDMX standard, organized by type of queries. The default media type is highlighted in bold.
@@ -55,3 +75,7 @@ Compression could be enabled using the appropriate [Accept-Encoding header](http
55
75
The [Vary header](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) is used to indicate the list of headers that are relevant for a particular service.
56
76
57
77
For example, services that offer data in multiple formats will rely on the HTTP Accept header, but this header will likely be irrelevant for services that support only one format. Using the `Vary` header to indicate which headers are effectively used by the server helps web caches and Content Delivery Networks to build appropriate cache keys.
78
+
79
+
### A note about SDMX-CSV
80
+
81
+
SDMX-CSV offers the possibility to set the value for two parameters via the media-type. These parameters are `label` and `timeFormat`; both are optional. The default values for these parameters are marked with * in the above media-type (i.e. `id` and `original` respectively). For additional information about these parameters, please refer to the [SDMX-CSV specification](https://sdmx.org/?sdmx_news=sdmx-csv-format-specifications-just-released).
0 commit comments