| 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 addressis not provided for e.g. security reasons, what text should be used?
- The example will remain as it is for the moment until the registry CCB gets back with an approach (see below).
|
| Support |
| The interoperability goal | - Good documentation on the need for interoperability is needed. What should we do?
|
| FAQ | - Questions to be answered (if you have ideas please send them to the group):
- How do I describe a service that uses GraphQL?
|
| SWIM service ecosystem |
| Standardised Implementations | |
| Service Categories - Service Type | - Update and Finish - OK to use?
- Dedicated meetings took place for this and the end result is now available. It is felt to be good enough to use for now but it is accepted that new values will be added as service implementation continues.
|
| 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 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.
- 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.
- The list of fields that can be toggled will be added to the documentation.
- This does not help when the service provider want to hide the endpoint from authenticated users.
|