blob: bf2ffbf2dfb23cc879b15e7ddb2e7679f953dcb3 [file] [log] [blame]
Ralph Knag1fca6ac2017-12-05 12:05:57 -05001.. This work is licensed under a Creative Commons Attribution 4.0 International License.
2.. http://creativecommons.org/licenses/by/4.0
3
4.. _data-formats:
5
Ralph Knagd2cd31b2018-04-02 16:27:46 -04006
Ralph Knag1fca6ac2017-12-05 12:05:57 -05007Data Formats
8============
9
Ralph Knagd2cd31b2018-04-02 16:27:46 -040010Data formats are descriptions of data; they are the data contract
11between your component and other components. When the components are
12composed into services in the SDC tool, they can only be matched with
13components that have compatible data formats. Data formats will be
14onboarded to SDC and assigned a UUID at that time. This UUID is then
15used to ensure compatibility amoung components. (If component X outputs
16data format DF-Y’, and another component Z specifies DF-Y as its
17input data format, then X is said to be ``composable`` with component
18Z).
Ralph Knag1fca6ac2017-12-05 12:05:57 -050019
Ralph Knagd2cd31b2018-04-02 16:27:46 -040020Since data formats will be shared across components, the onboarding
21catalog should be checked first to see if the desired data format is
22available before creating one. The vision is to have a repository of
23shared data formats that developers and teams can re-use and also
24provide them the means to extend and create new custom data formats. A
25data format is referenced by its data format id and version number.
26
27JSON schema
28-----------
29
30 The data format specification is represented (and validated) against
31 this `Data Format json schema <https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/cli.git;a=blob;f=component-json-schemas/data-format/dcae-cli-v1/data-format-schema.json;h=66aa2ab77449e3cafc6afb5c959c5eb793ad86c1;hb=HEAD>`__
32 and described below:
Ralph Knag1fca6ac2017-12-05 12:05:57 -050033
34Meta Schema Definition
Ralph Knagd2cd31b2018-04-02 16:27:46 -040035~~~~~~~~~~~~~~~~~~~~~~
Ralph Knag1fca6ac2017-12-05 12:05:57 -050036
37The Meta Schema implementation defines how data format JSON schemas
38can be written to define user input. It is itself a JSON schema (thus it
39is a meta schema”). It requires the name of the data format entry, the
40data format entry version and allows a description under self object.
41The meta schema version must be specified as the value of the
Ralph Knagd2cd31b2018-04-02 16:27:46 -040042dataformatversion key. Then the input schema itself is described as
43one of the four types listed below:
Ralph Knag1fca6ac2017-12-05 12:05:57 -050044
Ralph Knagd2cd31b2018-04-02 16:27:46 -040045+------------------+---------------------------------------------------+
46| Type | Description |
47+==================+===================================================+
48| jsonschema | inline standard JSON Schema definitions of JSON |
49| | inputs |
50+------------------+---------------------------------------------------+
51| delimitedschema | delimited data input using a JSON description and |
52| | defined delimiter |
53+------------------+---------------------------------------------------+
54| unstructured | unstructured text, and reference that allows a |
55| | pointer to another artifact for a schema. |
56+------------------+---------------------------------------------------+
57| reference | allows for XML and Protocol Buffers schema, |
58| | but can be used to reference other JSON, |
59| | delimitedschema and unstructured schemas as well. |
60+------------------+---------------------------------------------------+
Ralph Knag1fca6ac2017-12-05 12:05:57 -050061
Ralph Knag1fca6ac2017-12-05 12:05:57 -050062
Ralph Knagd2cd31b2018-04-02 16:27:46 -040063Example Schemas
64---------------
Ralph Knag1fca6ac2017-12-05 12:05:57 -050065
66By reference example - Common Event Format
67~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68
69First the full JSON schema description of the Common Event Format would
70be loaded with a name of Common Event Format and the current version
71of 25.0.0”.
72
73Then the data format description is loaded by this schema:
74
75::
76
77 {
78 "self": {
79 "name": "Common Event Format Definition",
80 "version": "25.0.0",
81 "description": "Common Event Format Definition"
82
83 },
84 "dataformatversion": "1.0.0",
85 "reference": {
86 "name": "Common Event Format",
87 "format": "JSON",
88 "version": "25.0.0"
89 }
90 }
91
92
93
94Simple JSON Example
95~~~~~~~~~~~~~~~~~~~~~~~~
96
97
98::
99
100 {
101 "self": {
102 "name": "Simple JSON Example",
103 "version": "1.0.0",
104 "description": "An example of unnested JSON schema for Input and output"
105
106 },
107 "dataformatversion": "1.0.0",
108 "jsonschema": {
109 "$schema": "http://json-schema.org/draft-04/schema#",
110 "type": "object",
111 "properties": {
112 "raw-text": {
113 "type": "string"
114 }
115 },
116 "required": ["raw-text"],
117 "additionalProperties": false
118 }
119 }
120
121Nested JSON Example
122~~~~~~~~~~~~~~~~~~~~~~~~
123
124::
125
126 {
127 "self": {
128 "name": "Nested JSON Example",
129 "version": "1.0.0",
130 "description": "An example of nested JSON schema for Input and output"
131
132 },
133 "dataformatversion": "1.0.0",
134 "jsonschema": {
135 "$schema": "http://json-schema.org/draft-04/schema#",
136 "properties": {
137 "numFound": {
138 "type": "integer"
139 },
140 "start": {
141 "type": "integer"
142 },
143 "engagements": {
144 "type": "array",
145 "items": {
146 "properties": {
147 "engagementID": {
148 "type": "string",
149 "transcript": {
150 "type": "array",
151 "items": {
152 "type": {
153 "type": "string"
154 },
155 "content": {
156 "type": "string"
157 },
158 "senderName": {
159 "type": "string"
160 },
161 "iso": {
162 "type": "string"
163 },
164 "timestamp": {
165 "type": "integer"
166 },
167 "senderId": {
168 "type": "string"
169 }
170 }
171 }
172 }
173 }
174 }
175 }
176 },
177 "additionalProperties": false
178 }
179 }
180
181Unstructured Example
182~~~~~~~~~~~~~~~~~~~~~~~~~
183
184::
185
186 {
187 "self": {
188 "name": "Unstructured Text Example",
189 "version": "25.0.0",
190 "description": "An example of a unstructured text used for both input and output for "
191
192 },
193 "dataformatversion": "1.0.0",
194 "unstructured": {
195 "encoding": "UTF-8"
196 }
197 }
198
199
200An example of a delimited schema
201--------------------------------
202
203::
204
205 {
206 "self": {
207 "name": "Delimited Format Example",
208 "version": "1.0.0",
209 "description": "Delimited format example just for testing"
210
211 },
212 "dataformatversion": "1.0.0",
213 "delimitedschema": {
214 "delimiter": "|",
215 "fields": [{
216 "name": "field1",
217 "description": "test field1",
218 "fieldtype": "string"
219 }, {
220 "name": "field2",
221 "description": "test field2",
222 "fieldtype": "boolean"
223 }]
224 }
225 }
Ralph Knagd2cd31b2018-04-02 16:27:46 -0400226
227Note: The referenced data format (in this case, a schema named Common
228Event Format with version of 25.0.0”) must already exist in the
229onboarding catalog.
230
231Working with Data Formats
232-------------------------
233
234Data Formats can be added to the onboarding catalog (which first
235validates them) by using the :doc:`dcae_cli Tool <dcae-cli/quickstart/>`.
236Here you can also list all of your data formats, show the contents of a
237data format, publish your data format, and even generate a data format
238from a input sample file. For a list of these capabilities, see :any:`Data Format Commands <dcae_cli_data_format>`.