Venue
Date: 16 Mar 2020 1400-1530
webex link: https://eurocontrol-conferences.webex.com/join/wvanhamm | 706 775 248
Agenda
ID | Title | start | duration |
---|---|---|---|
1 | Welcome | 14:00 | 10' |
2 | Common elements | 14:10 | 15' |
3 | Update on SSCONE tasks | 14:25 | 40' |
4 | Update on SITCOM tasks | 15:05 | 15' |
5 | Any other business | 15:20 | 10' |
6 | Close | 15:30 | - |
Panel | ||||
---|---|---|---|---|
| ||||
|
Welcome
Objectives of this meeting are:
- refine work plan
- progress on tasks
Common elements
None
Update on SSCONE tasks
The updated task list is at SSCONE Tasks.
Service Description Schema
Evolving objectives & activities
Excerpt from F2F meeting.
- Support effective implementation
- support MET services … ?
- support other services …
- Being more practical
- service description format (template / Schema)
- service classification / categories
- More ?
- service definition
- provider agnostic service descriptions that facilitate alignment and interoperability in the implementation of services
- prospective service
- guidelines for describing services that are not operational yet (~candidate service)
- service definition
- other ideas?
- Registry needs to be made live.
- Risk exists however that it will be full of services that nobody uses.
- Operational use may be slow to pick up at least in ATM. UTM may be quicker
- geofencing initiatives may not be aligned
- nice to look at WFS for METAR services
- identify simple use cases where SWIM makes an impact (eg should we be starting with UTM?)
- make the conformance evidence a stronger requirement
- check the registry conforms to the specs
- consider PANS - it will lead to service overviews
- still focus on the "used effectively" part of the initial objectives. The word support is too strong, it is give advice and highlight advice.
Proposed main task
Practically applying the Service Description specification by having service descriptions in structured notation.
Starting point is the JSON Schema as being used by SWIM Registry.
outcome:
- It has been clarified that SSCONE is the forum to discuss the Service Description Schema, taking the needs of the SWIM Registry into account.
- According to the comments raised, working sessions (webex initially) will be defined for detailed discussions on the Schema.
Proposed additional tasks
As not many services are already operational, there's a need to describe
- prospective services: service instances that are not operational yet (related to the notion of candidate service).
- service definitions.
These notions will be looked at more closely, in relation with the Schema and the Registry. Taking the service description specification in mind.
The updated task list is at SSCONE Tasks.task | description | status | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
/wiki/spaces/SCOI/pages/59605512 |
|
The Service Description Schema is our main task for the beginning of the year.
- /wiki/spaces/SCOI/pages/59606102 explains the context with origin and objectives.
- /wiki/spaces/SCOI/pages/59606244 provide the log of releases of the schema
Assessment and feedback received:
- /wiki/spaces/SCOI/pages/59605552 is an initial assessment looking mostly at conformance to the SD spec.
- Renato provided comments on that assessment (see /wiki/spaces/SCOI/pages/59605552)
- the comments stress the need for the schema to cover all information elements from the ICAO Service Overview.
- /wiki/spaces/SCOI/pages/59606141 intents to collect the result of our assessment
Work sessions will be defined for detailed discussions.
- Please express your interest to be part of work sessions
outcome:
Discussions, comments received
- The XML Schema from SWIM Governance was found more structured and easier to use. The embedded rules of what is mandatory or optional was very appreciated. In comparison producing a Service Description using the current JSON Schema brings additional difficulties.
- JSON in itself is not questioned. However the current schema involves more manual work due to poor tooling. Expectation is to get the same level of support as was available with the XSD.
- There is a need for a clear view on the rules, guidance, and tooling. There is a need to do own validation, without having to upload in the Registry. At short term there is the need to know what are the mandatory items. For longer term the expectation is that the schema and tooling would be such that people don't have to read documents / policies / spec.
- There was a comment about the use of ISO 19115 to increase interoperability. Some examples are needed to make clear the impact on the Schema.
- A first series of findings, initially intended for use in Registry CCB, was made available at the end of the meeting (available here).
All these needs will drive our work in the /wiki/spaces/SCOI/pages/59605512.
Call for participation to work sessions will be sent later this week.
Update on SITCOM tasks
The updated task list is at SITCOM Tasks.The first task to start this year is Semantic correspondence training material. A call for interest will be sent to the COI to ask for participation in drafting the material. Work will be done by a series of review
webexsWork has started on the FAQ - Semantic correspondence.
- WebEx invitations have been sent to those interested in contributing to the task.
- Next WebEx is on 31 March when the first set of inputs will be reviewed.
Any other business
Use of specifications
Questions:
- Progress on use of the spec? Difficulties encountered?
- Examples to be shared, or to work on?
Next meetings
Meeting schedule is maintained at SSCONE-SITCOM ScheduleMeetings.
Next progress meeting on 16th Mar 27th Apr 1400.Is there already a need to identify a face-to-face meeting?