Extend S3I service (and value?) description in the directory with schema information
Based on the proposed extension to include S3I events in the S3I Directory model, the current parameter description for services should be adapted in a similar fashion. A typical service description currently looks like the following:
{
"serviceType": "thingServiceType",
"endpoints": ["s3ibs://s3i:1234"],
"parameterTypes": {
"identifier": "string"
},
"resultTypes": {
"result": "boolean"
}
}
With respect to the proposed event scheme, a service description could look like the following:
{
"endpoints": [
{
"uri": "s3ib://rabbitmq.s3i.vswf.dev:5672/s3i/demo.exchange/s3i:1234",
}
],
"serviceType": "thingServiceType",
"description": "This service ...",
"parameters": {
"dataformat": "json",
"schemaType": "JSONSchema",
"schema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "???",
"description": "JSON Schema for the parameter field of this ServiceRequest",
"properties": {
"idenifier": { "type": "number" },
}
}
},
"results": {
"dataformat": "json",
"schemaType": "JSONSchema",
"schema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "???",
"description": "JSON Schema for the results field of this ServiceRequest",
"properties": {
"result": { "type": "boolean" },
}
}
}
}
Some questions remain:
- What would the "title" field represent?
- How can we describe more complex dataTypes, e.g. fml40 documents instead of a "nummber" or "string"? Should the document be breaken down to a JSON schema and inserted at the respective field. Should the fml40 document schema be avaialable somewhere else to comprehend the structure?
- With rising amount of services, this description enlarges the model size rapidly. Is this in conflict with the size of the ditto?
- All the questions from above also apply for values and their respective description.
Edited by Anil Riza Bektas