| 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 and approach for withheld endpoints. We will wait on updated SWIM Registry documentation on the fields that can be hidden before reactivating our task.
|
| 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 We checked 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 bodyIt has a lifecycle status field coming from the SWIM Governance Implementing Project.- There is no conformance checking flag as such.
- There is not much more SSCONE-SITCOM can do in this area so the action will be closed.
|
| FAQ | - Questions to be answered (send suggestions to the group):
- How do I describe a service that uses GraphQL? Some example of services that use GraphQL will be presented at a future meeting so that we can begin to see how it fits into the SWIM specifications.
|
| Service Metadata Schema | request made to the draft v1.0.0 service metadata schema to add support for more than one reference to an information definition. The justification was to allow those who use an *XM model and one or more of its extensions to refer to them all.
This will impact the examples used in our supporting material.
| 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 |
| Documenting the use of standardised implementations | |
| Code Block |
|---|
| language | js |
|---|
| title | Example of SWIM-SERV-290 using Service Metadata Schema |
|---|
| "informationDefinition": {
"reference": [{
"description": "Aeronautical Information Exchange Model (AIXM) 5.1.1",
"url": "https://www.aixm.aero/schema/5.1.1/AIXM_Features.xsd"
},
{
"description": "Event Extension for AIXM 5.1.1",
"url": "https://www.aixm.aero/schema/5.1.1/event/version_5.1.1-i/Event_Features.xsd"
}]
} |
Other examples will also need to be updated to reflect the use of the array. |
| SWIM service ecosystem |
| Service Design Activities | - We have no where to publish pages on service design as of yet. What approach is preferred?
- The group discussed this briefly. It is happy to engage more in this. It would be an expansion in our scope so there is a need to inform IMT.
- Still to do: To describe an implemented service that uses AMQP 1.0 in an harmonised way it would be good to visit the categorisation schemes and indicate which of the elements in the relevant schemes are expected to be used. For instance: CodeApplicationMessageExchangePatternType. PUBLISH_SUBSCRIBE etc. In general would expect on this page also categorisation related information.
|
| /wiki/spaces/SCOI/pages/59606413 | - More meetings focusing on FF-ICE services and AMQP are needed.
- Initial contact with the FF-ICE group made in order to get an understanding. Hopefully there will be an action plan by the next progress meeting.
|
| 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.
|