Ongoing discussions within the SWIM communities of interest

Page tree

Ongoing discussions within the SWIM communities of interest

Skip to end of metadata
Go to start of metadata

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 foundational 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. Is it possible to use the materials from “Get into SWIM” session in other contexts to promote the harmonisation further?

Answer: Yes. EUROCONTROL specs are open and publicly available. Conformance is voluntary. When groups start to implement based on the requirements, this COI will not check any of the resulting implementations for conformity.

Note: the materials from “Get into SWIM” session is publicly available at "Get into SWIM" - presentations 

Task Process Change Request 168/1

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 (Process change request 169/1) 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

presentation_beringer20190523.zip


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 Basic steps for new services 

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: Process Change Request 168/1Conformance assessmentBasic steps for new services

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

TaskDescriptionStatusPriority
individual requirements


SWIM-SERV-009 Service categories

rework terminology and reference to existing schemes

  • notion of "scheme" not very clear

  • example confusing


2
Service Categorisation Scheme

Example not very clear: confusion between serv desc & registry categories

  • Separate the Registry categories
  • Separate Status (as this is added to cover non-implemented 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.

removeno
Donlon TOBT Setting examplereordering of sections for better readability (eg business experts, developers)
  • Any suggestion?
  • Still needed on top of Table of Content?

outcome:

Not much interest. See below however.

removeno
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 Conformance assessment.

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:

  • Add a link to the compliance material from SWIM Governance IP .
  • Add a diagram to link the various groups e.g. EASCG

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 - Service descriptions

outcome:

To be update with some of the questions raised during the meeting


2

SSCONE meetings

See SSCONE Meeting Notes.

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.
  • No labels