Venue
Date: 23rd May'19 0900-1600
ECTL HQ ; Neptune Room
Agenda
Item | Title | Content | Time |
|---|---|---|---|
0 | Welcome | Welcome, Agenda, Introduction | 0900 |
1 | Change Request | Advice on handling CR 168/1 | 0920 |
2 | Sharing experience | Applying the spec to a Meteorological Data Service (MET Service) (By Steffen Beringer) | 1020 C |
3 | Conformance to the spec | Terminology, Assessment, Resources. | 1150 L |
4 | SWIM Compliance | SWIM compliance (By Oliver Krüger) | 1320 |
5 | Basic steps to new services | Service Orientation Process, Interoperability Architecture, Service Overview Service Identification Document | 1350 |
6 | Next steps | Potential tasks, Priorities. Voice your interests | 1430 C |
7 | Any other business | 1540 | |
- | Close | 1600 |
C & L: Coffee and Lunch Breaks are indicative.
Main presentation
Most agenda points have been using this presentation.
Introduction
Slides 3 to 8 in main presentation.
Question raised: Would we consider using a more secure platform for discussions rather than WebEx. Thinking about security upfront.
Answer: doesn't seems to be a shared concern at the moment.
Question raised: What about with ETSI, etc.
Answer: Various standardization bodies deal with different aspects. ETSI – security, EUROCAE – specific standards, EUROCONTROL – specifications, EASA – rules, etc. This is a complex environment. EASCG coordinates the various groups through the rolling roadmap
Question raised: Will there be a harmonization effort e.g. does DONLON example following what SWIM Governance proposes for XSD.
Answer: The specification gives the requirements. The DONLON example satisfies the requirements – see the supporting material. This is not the forum to discuss the XSD.
Question raised: From an activities point of view, there is a lot of coordination between the organisations. The spec is the glue. EASA has a rulemaking task for SWIM but has done nothing yet. Is it possible to use the materials from “Get into SWIM” session in other contexts to promote the harmonization further?
Answer: EUROCONTROL specs are open, voluntary. Then groups start to implement the rules. This COI will not control the fine-grained implementation of the requirements by all of those groups.
Task /wiki/spaces/SCOI/pages/59606015
See slide 9 to 18 in main presentation.
There were good discussions about
- the various interpretations of the original requirement (the one in consultation).
- the corresponding Information Definition CR (/wiki/spaces/SCOI/pages/59605881) that was discussed on Tuesday in SITCOM, and the advice to make some changes.
- the rationale for having 3 specifications to separate and manage the PCP concerns. Reverting back, with the meaning of requiring AIRM conformane within the Serv Desc spec, would break the separation.
- Published text is clearer so keep it as is.
The advice from the Community is "No change required".
Share Experience – MET Service (By Steffen Beringer)
Presentation
MET Service material
IWXXM is seen as complicated and bloated. This seems to be agreed by teh audience.
- Schemas are complicated and import AIXM
- Encoding is 200 times larger than the old text (eg from 100 bytes to 20 kilobytes). With parsing energy.
Question from the audience:
- Why using a new feature name?
- Is paging available? How is this related to the maximum number of features per request?
Questions from Steffen (see before last slide):
- where to describe the limiting constraint of 200 features per request: in consumption constraint or in technical constraint → to be defined in Guidance.
- Is there a need to detail the WFS calls (i.e. the service operations) as these are a known part of the standard? Same for the filters. → to be added to FAQ.
Task Conformance assessment
see slides 20 to 25 in main presentation
Questions raised: Is there something beyond conformance to the specification through self-assessment.
Answer: Not when it comes to conformance to the specification. In a wider context, there are the notions of PCP compliance to iSWIM (ISRM part) and SWIM compliance (see below next agenda point)
SWIM Compliance (By Oliver Krüger)
Presentation
Oliver indicated that there is overlap between Governance and COIs. In the future the governance could use COIs as an expert group.
Task /wiki/spaces/SCOI/pages/59605910
See slides 27-30 in main presentation
There's a new page in the handbook containing material about the Basic steps to new services
Next steps
Active Tasks
The 3 active tasks have been addressed as specific agenda point: /wiki/spaces/SCOI/pages/59606015, /wiki/spaces/SCOI/pages/59605293, /wiki/spaces/SCOI/pages/59605910
Prioritising potential tasks
Each task within the SSCONE Tasks page has been discussed. See below
- the "outcome" of the discussion
- the priority, and the status
| Task | Description | Status | Priority |
|---|---|---|---|
| individual requirements | |||
| SWIM-SERV-009 Service categories | rework terminology and reference to existing schemes
| 2 | |
| Service Categorisation Scheme | Example not very clear: confusion between serv desc & registry categories
| 2 | |
| SWIM-SERV-011 Operational needs | Provide good examples of OSED. outcome: OSED is a large document. We need to be more precise on the sections of the OSED we can isolate e.g. operational needs and requirements sections. Look for good examples of these and use cases. Unclear who raised this. Unclear the added value. Not a priority. | no | |
| requirements without guidance | outcome: Provide a page for every requirement and say “no further guidance is provided” where appropriate. | 2 | |
| Basic steps for new service | |||
| Service Orientation Process | Useful? Use as complementing material ? outcome: This is useful but we should not overdue it. The current situation (copy of the draft ICAO Manual) is sufficient. No further work. | To be closed | - |
| Interoperability Architecture | Useful? Use as complementing material ? outcome: This is useful but we should not overdue it. The current situation (copy of the draft ICAO Manual) is sufficient. No further work. | To be closed | - |
| ICAO Service Overview | Document in handbook (ICAO Service Overview). Gap analysis: Compare with service description (Service Overview mapping). Bridge the gap with guidance in Handbook. outcome: This is not a priority for the community. This will be kept internal to ECTL currently. | 4 | |
| Service Identification Document (SID) | Making use of the "A-CDM services identification" example. outcome: This would be a good idea to work on. It relates to the Basic steps to new services, specifically to the identification step in the Service Orientation Process. It could result in a template for use by others. Pre-requisite: internal review before sharing with the Community. | 2 | |
| Resources | |||
| Donlon TOBT Setting example | update the Donlon Service Description AIRM traces to use the AIRM 1.0.0. | completed | - |
| Donlon TOBT Setting example | XML to be updated to XML v1 outcome: Not much interest. See below however. | remove | no |
| Donlon TOBT Setting example | reordering of sections for better readability (eg business experts, developers)
outcome: Not much interest. See below however. | remove | no |
| Donlon TOBT Setting example | Going for an implemented service? (would be together with SWIM-TEC) outcome: There's an interest in continuing to improve the example. And also to collect examples provided by the COI members. Allows for peer review of each other’s work. | ||
| --DONLON Flight Publication example | outcome: Flight publication example is useful as it covers two of the most popular MEPs. Pre-requisite: finalise in line with the "Get into SWIM" presentations. | 2 | |
| Clarify links with other SWIM specs | Make a clear picture of the how the 2 other SWIM specs relate to the SWIM Serv desc spec outcome: no enthusiasm for a diagram of relation between the 3 specs | no | |
| Outside spec's scope | |||
Describing non-implemented services | This has alsready been started in non-implemented service outcome: Non-implemented services could be described using a subset of the service description requirements. This is about using the spec outside its initial scope. One way forward could be to align with the governance. For instance, to let governance finish its work, then SSCONE can take it over and maintain it in the future. | 3 | |
| Harmonising service design | Possible re-use of output from SESAR 1. See eg --naming conventions, service design outcome: Naming conventions could prove useful. No enthusiasm to invest, but if we can re-use from SESAR 1, why not. | 3 | |
| SWIM compliance | requires coordination with SWIM Governance Implementation Project This is handled somewhat in /wiki/spaces/SCOI/pages/59605293. outcome: Questions raised: Do we develop a SWIM compliance process? Do we show how we fit into the overall picture hooking the specs to the SWIM compliance process? Decision is:
| 2 | |
| SLA | Define an SLA -template to provide some good practice on what the Providers and consumers should "talk" about in Terms of Service quality. (see some subjects in service design). outcome: This is welcome. | 2 | |
| FAQ | outcome: To be update with some of the questions raised during the meeting | 2 |
SSCONE meetings
See SSCONE Meetings.
This point has not been addressed during the meeting.
**after the meeting, it was decided to move the next webex from 3rd June to 11th June.
AOB
Suggestions for the future
- a Forum/Open Session once a year
- a sandbox for service implementations. Where people can put their services, try, and get feedback.
- Have a structured description allowing to separate logical from technical ==> allow re-using same logical with different technolgies / endpoints.