Agenda

Item	Time
Welcome	1400
Update on tasks
Any other business
Close	1530

Welcome

Objectives of this meeting are:

discuss next year's arrangements
work on tasks

Next year

The same 6-weekly schedule is kept. Meeting updates have been sent.

Update on tasks

Completed tasks

-

Ongoing tasks

Task	Notes
Artefacts to describe services
Service Definitions supporting material	No updates required. Template is being used for aeronautical service definitions.
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. 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?
SWIM service ecosystem
Documenting the use of standardised implementations	Documenting the use of standardised implementations: It can move to supporting material once the minor outstanding comments are addressed. Design aspects - we have no where to publish these as of yet. Comments were made directly on the page.
/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 service implementation continues. 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	Open request: provide examples of the typical exchanges that can be mapped to a given category e.g. what falls under “Capacity, demand and flow information”. This can be worked on in 2023. It will focus on listing service definitions and on detailing the relationships between the services that are being defined.
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.

Any other business

none

Next meetings

Meeting schedule is maintained at SSCONE-SITCOM Meetings.

Next progress meeting is 30 January 2023.

SWIM Community of Interest

2022-12-19-SSCONE-SITCOM