Skip to end of metadata
Go to start of metadata
Item | Time |
|---|
| Welcome | 1400 |
Update on tasks |
|
Any other business |
|
| Close | 1530 |
Objectives of this meeting are:
Task | Notes |
|---|
| Support |
| FAQ | Question and answer on HTTP Error codes was moved to the supporting material |
| SWIM service ecosystem |
| Service Categories | The categories reviewed at the previous meeting were moved to the reference website |
| Task | Notes |
|---|
Artefacts to describe services
|
| Service Definitions supporting material | |
| Service Descriptions supporting material | - Comments to be resolved (if you have ideas please send them 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?
- Note that GML has the following enumeration which was used for inspiration in the current example:
- "inapplicable": there is no value
- "missing": the correct value is not readily available to the sender of this data. Furthermore, a correct value may not exist
- "template": the value will be available later
- "unknown": the correct value is not known to, and not computable by, the sender of this data. However, a correct value probably exists
- "withheld": the value is not divulged
- Concerns were raised about the ability to withhold the network address - if a service is not reachable, should it be in the registry at all?
- It was pointed out that the example is for service descriptions in general.
- The representation in the registry is another concern. The registry is a design time registry, not a run time registry. The registry CCB should be asked if it is possible to have authenticated and non-authenticated users. That would allow certain fields to be only seen by authenticated users. Non-authenticated users could see something like the /wiki/spaces/BOK/pages/59409601 fields only.
- The example will remain as it is for the moment until the registry CCB gets back with an answer.
|
| Support |
| Conformance/compliance assessment report templates | - It was decided that we will not engage in preparing templates like this for now.
- See 2022-09-26-SSCONE-SITCOM for the example templates.
- The assessment_template_introduction.pptx was used to introduce the topic.
- It was pointed out that it is possible to use a local PKI that conforms with the European PKI. The compliance template has the word "use". It should be updated to "use of complies with".
- The NM B2B SWIM compliance documentation is available on their OST for those with access.
- The group discussed how to better document the fact that interoperability is the goal of the SWIM activities.
- The fact that a service implementation:
- try to conform with existing service definitions and
- try to use standardised implementation based on the SWIM TIYP help with this.
- The domains and other communities create the service definitions (see e.g. https://ext.eurocontrol.int/swim_confluence/display/ASW/Aeronautical+SWIM+Services). Much of the interoperability discussions happens in those groups.
- However, some good documentation on the need for interoperability is still needed.We can discuss this further at the next meeting.
|
| FAQ | - Questions to be answered (if you have ideas please send them to the group):
- How do I describe a that uses GraphQL?
|
| SWIM service ecosystem |
| Standardised Implementations | The group reviewed the work after the split into two sections: The group will review the content and provide further examples before the next meeting. We can decide it the work can be completed at the next meeting.
|
| Service Categories - Service Type | - Dedicated meetings on this. Next one is 28th November.
|
| 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”.
- Hopefully the work on service categories will help answer this.
|
Registry.
- New schema version is still in test.
Meeting schedule is maintained at SSCONE-SITCOM Meetings.
Next progress meeting is 19 December