Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 1 | .. 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 Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 6 |
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 7 | Data Formats
|
| 8 | ============
|
| 9 |
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 10 | Data formats are descriptions of data; they are the data contract
|
| 11 | between your component and other components. When the components are
|
| 12 | ‘composed’ into services in the SDC tool, they can only be matched with
|
| 13 | components that have compatible data formats. Data formats will be
|
| 14 | onboarded to SDC and assigned a UUID at that time. This UUID is then
|
| 15 | used to ensure compatibility amoung components. (If component X outputs
|
| 16 | data format ‘DF-Y’, and another component Z specifies ‘DF-Y’ as its
|
| 17 | input data format, then X is said to be ``composable`` with component
|
| 18 | Z).
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 19 |
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 20 | Since data formats will be shared across components, the onboarding
|
| 21 | catalog should be checked first to see if the desired data format is
|
| 22 | available before creating one. The vision is to have a repository of
|
| 23 | shared data formats that developers and teams can re-use and also
|
| 24 | provide them the means to extend and create new custom data formats. A
|
| 25 | data format is referenced by its data format id and version number.
|
| 26 |
|
| 27 | JSON 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 Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 33 |
|
| 34 | Meta Schema Definition
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 35 | ~~~~~~~~~~~~~~~~~~~~~~
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 36 |
|
| 37 | The “Meta Schema” implementation defines how data format JSON schemas
|
| 38 | can be written to define user input. It is itself a JSON schema (thus it
|
| 39 | is a “meta schema”). It requires the name of the data format entry, the
|
| 40 | data format entry version and allows a description under “self” object.
|
| 41 | The meta schema version must be specified as the value of the
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 42 | “dataformatversion” key. Then the input schema itself is described as
|
| 43 | one of the four types listed below:
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 44 |
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 45 | +------------------+---------------------------------------------------+
|
| 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 Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 61 |
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 62 |
|
Ralph Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 63 | Example Schemas
|
| 64 | ---------------
|
Ralph Knag | 1fca6ac | 2017-12-05 12:05:57 -0500 | [diff] [blame] | 65 |
|
| 66 | By reference example - Common Event Format
|
| 67 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| 68 |
|
| 69 | First the full JSON schema description of the Common Event Format would
|
| 70 | be loaded with a name of “Common Event Format” and the current version
|
| 71 | of “25.0.0”.
|
| 72 |
|
| 73 | Then 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 |
|
| 94 | Simple 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 |
|
| 121 | Nested 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 |
|
| 181 | Unstructured 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 |
|
| 200 | An 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 Knag | d2cd31b | 2018-04-02 16:27:46 -0400 | [diff] [blame] | 226 |
|
| 227 | Note: The referenced data format (in this case, a schema named “Common
|
| 228 | Event Format” with version of “25.0.0”) must already exist in the
|
| 229 | onboarding catalog.
|
| 230 |
|
| 231 | Working with Data Formats
|
| 232 | -------------------------
|
| 233 |
|
| 234 | Data Formats can be added to the onboarding catalog (which first
|
| 235 | validates them) by using the :doc:`dcae_cli Tool <dcae-cli/quickstart/>`.
|
| 236 | Here you can also list all of your data formats, show the contents of a
|
| 237 | data format, publish your data format, and even generate a data format
|
| 238 | from a input sample file. For a list of these capabilities, see :any:`Data Format Commands <dcae_cli_data_format>`.
|