| 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 address is not provided for e.g. , 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 that uses GraphQL?
|
| SWIM service ecosystem |
| Documenting the use of standardised implementations | |
| /wiki/spaces/SCOI/pages/59606413 | - Dedicated meetings took place for this and the end result is now available. It is maturing but it is accepted that new values will be added as . Therefore, do not publish on the reference website yet. 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.
|