| Task | Notes |
|---|
Artefacts to describe services
|
| Service Definitions supporting material | |
| Service Descriptions supporting material | - Comments to be resolved (send suggestions to the group):
- SWIM-SERV-240 Service interfaces - If the fully qualified network addressis not provided for e.g. security reasons, what text should be used?
- There is now a need to clarify if the use case for hiding the endpoint is still valid given the existence of authenticated users in the registry.
|
| Support |
| The interoperability goal | - Good documentation on the need for interoperability is needed. There is high-level material at: https://reference.swim.aero/what-is-swim.html?
- From SSCONE-SITCOM
- Adoption of services is the key
- Reuse of standards including service definitions is fundamental
- they cover aspects of organisational and technical interoperability
- they contribute to interoperability based on the concreteness of the requirements they contain, including requirements on the data.
- We should check if the Registry has a "flag" for conformance checking based on req-120.
- Example from maritime world: A flag in the service registry that conformance checks with standard have been done. Manual check, but attempt to also (difficult) automate it e.g. check WFS operations re actually implemented.
- However, interoperability goes beyond conformance with the standards - this final step is beyond the scope of SSCONE-SITCOM.
- an authority could check the conformance statements: EASA or national regulatory authority or another body.
|
| FAQ | - Questions to be answered (send suggestions to the group):
- How do I describe a service that uses GraphQL?
|
| Service Metadata Schema | Support Change request to add support for more than one reference . Will to an information definition. Main reason is use of an *XM model and one or more of its extensions.
This will impact examples.
| old | new |
|---|
"informationDefinition": {
"description": "A formal representation of information concepts or data concepts. [SWIM-SERV-290]",
"oneOf": [
{
"type": "object",
"properties": {
"reference": {
"$ref": "#/definitions/Reference"
}
}
},
{
"type": "array",
"items": {
"$ref": "#/definitions/InformationDefinition"
},
"minItems": 1
}
] | "informationDefinition": {
"description": "A formal representation of information concepts or data concepts. [SWIM-SERV-290]",
"oneOf": [
{
"type": "object",
"properties": {
"reference": {
"type": "array",
"items": {
"$ref": "#/definitions/Reference"
},
"minItems": 1
}
}
},
{
"type": "array",
"items": {
"$ref": "#/definitions/InformationDefinition"
},
"minItems": 1
}
] |
|
| SWIM service ecosystem |
| Standardised ImplementationsDocumenting the use of standardised implementations | |
| Service Categories - Service Type | - More meetings focusing on FF-ICE services and AMQP are needed.
|
| Service Portfolio and Service Categories - Service Type | |
| Registry changes | - The registry CCB was asked if it is possible to have authenticated and non-authenticated users. That would allow certain fields to be only seen by authenticated users.
- Response: This is, in fact, the case already. It is possible to toggle the visibility of fields using the HTML based editor. This is often missed. Better documentation has been requested.
- Non-authenticated users could see something like the /wiki/spaces/BOK/pages/59409601 fields only.
- Response: The list of fields that can be toggled will be added to the documentation.
- Note: This does not help when the service provider wants to hide the endpoint from everyone including authenticated users.
|