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

Processing the received comments on the schema.

 Detailed Table of Content [+]

Summarised Table of Content

Comments on requirements' guidance

Julia 15 Jul'20

Because I can not comment in the handbook I add my comments to the JSON guideline here

  • Overall I think the guideline matured very well and provides way more help than before! :)


Comments on REQs:

SWIM-SERV-010 Service standard reference - processed

  • maybe add example with isConformant=TRUE and conformanceStatement="not an empty string but a description of some deviations ;)"
  • (Processing: example updated.)

SWIM-SERV-012 Service functionality - processed

  • Note is helpful, maybe link to REQ for Service Operation (SWIM-SERV-021)?
  • to provide relation of REQs --> similar to note in SWIM-SERV-013 with SWIM-SERV-019?
  • (processing: req 012 & 021 cross referenced in a note on business vs technical view)

SWIM-SERV-013 Access and use conditions - wait input

  • maybe add more examples for the other types (this REQ does cover quite a lot)
  • (processing: Oliver and/or Julia may provide input)

Examples related to service interfaces - processed

all examples regarding service interfaces (SWIM-SERV-016 Service interfaces +018 + 019 ... ?)

  • it seems the examples always are parts of the whole interface description... maybe it would be more comprehensible if there is one big example and the covered parts are highlighted (in bold or otherwise)
  • at the moment it is a bit confusing because it seems there are several service interface parts
  • (processing: 1) in 016 adding note and linking to related requirements. 2) example clarified by showing the other attributes. 3) related requirements have a link to 016.


  • still not sure what the added value of interfaceBindingDescription is (in comparison to the description within serviceInterface)
  • (processing: clarified during meeting: interface.description describe intent of the interface, while interface.interfaceBindingDescription provides additional info on the binding)

SWIM-SERV-022 Information definition - processed

  • would split the Guidance and cut the serviceInformation --> to be added in SWIM-SERV-023 / AIRM conformance
  • (processing: as discussed, it was preferred to add rationale for grouping the guidance.)


  • SWIM-SERV-022 then contains an exmple for serviceDocument type=INFORMATION_DEFINITION
  • would also add an example for type=AIRM_TRACE because this also is an available type
  • (processing: example added with semantic correspondence separate from information definition)

SWIM-SERV-025 Service behaviour - processed

  • still not clear why this is within serviceInterface....
  • (processing: 1) Note added to req to highlight confusion; 2) subject created in Schema evolution proposals)

Walk-through comments

Oliver 29 Apr'20

Oliver 0429a - Service Provider [answered]

Comment: why is it not called service provider as in the Spec, why is it not better specified , as in the Spec: 

  •  the name and description of the organisation responsible for the service; and
  • one or more points of contact where additional information can be obtained, including name, contact information and role.

Answer: This would indeed increase alignment with the specification.
It would even make more sense, if the dateInOperation attribute is moved out of this structure (see related comment).  See proposal Schema evolution proposals#ServiceProvider.

Comment from Oliver: accepted

Oliver 0429b - Compliant rules [answered]

Comment (on informationServices attributes serviceGeneralDescription, serviceInformationDescription, serviceTechnicalDescription, serviceInterface, serviceDescriptionReferences): not ok, we should make clear what compliant means , currently it is compliance to the ectl service spec, therefore this can not be mandatory . If compliance to the ICAO Service overview is needed, then the ECTL Spec should include those fields 

Answer: These attributes were not for review yet. But anyway, find below the answer.

  • These attributes are a way to structure the information using types. They act as container. It is expected that the detailed analysis of these types will reveal that each type is related to serv desc spec requirements. Hence the Mandatory indicator. 
  • These attributes are not related to the Service Overview requirements.

Comment from Oliver: These informations are already provided by  fields described in the Spec, e.g. ServiceAbstract, service Function, why adding redundant Information and making it mandatory. It gets really confusing, when we go away more and more from the spec.

If you want to introduce new fields as mandatory and don't want to Change the Spec permanently, we need to discuss other ways on the Management of the changes, e.g we could maintain a side document (Backlog?) where the agreed foreseen changes are documented so that everybody knows that there is not only the Spec itself as the leading document but also this second one , where he/she has to look at.

Oliver 0429c - Why here and later again [answered]

Comment (on DescriptionInformation and attributes serviceDescriptionIdentification and abbreviations): Why is that here and later on comes again?

Answer: A defined type appears twice: at one place it is used, at another place it is defined. This makes the review a little more tedious. (Note the same is occurring in the annex C of the Registry URD). 

Comment from Oliver: ok , misunderstanding from my side

Oliver 0429d - ProviderType is not in spec [answered]

Comment (on providerType within ServiceProvision): not mandatory, not in spec.

Answer: Indeed, this is not in spec, this is not required for conformance to spec. As indicated in Schema context, however, the schema task takes additional sources to define what is mandatory. 

  • The Annex C of Registry URD defines this as mandatory. This was also identified as a registry service category by the SWIM Governance in 2018. 
  • The attribute traces to SWIM-SERV-009 Service categories, as this is inline with the note "Note: It is best practice to include additional category information". 

Comment from Oliver: ok

Oliver 0429e - DateInOperation is not in spec [answered]

Comment: (on dateInOperation within ServiceProvision): not ok, not in spec.

Answer: Indeed, this is not in spec, this is not required for conformance to spec. As indicated in Schema context, however, the schema task takes additional sources to define what is mandatory. 

  • The Annex C of Registry URD defines this as mandatory. 
  • The attribute traces to ICAO Service Overview, as the Lifecycle part of the service overview states"Information on the service lifecycle stage indicating the status of the information service is in, as well the timeline". And further clarifies with a template "OPERATIONAL SINCE ddmmyyyy". Making de facto the dateInOperation as a required information for a service overview.
    • This will clarified in guidance material. (Action).

Comment from Oliver:  ok

Oliver 0429f - Why are service categories mandatory  [answered]

Comment: (on serviceType, lifeCycleStage, busisnessActivityType, intendedConsumer in ServiceCategorisation): why is this mandatory , it is not mentioned in the spec, if this needs to be mandatory, the spec needs to be adapted.

Answer: Indeed, this is not in spec, this is not required for conformance to spec. As indicated in Schema context, however, the schema task takes additional sources to define what is mandatory. 

  • The Annex C of Registry URD defines these as mandatory. These were also identified as service category by the SWIM Governance in 2018. 
  • Once this is stable and agreed, this will need to be fully document in the handbook. If needed, this could be part of an update to the spec.

Comment from Oliver: ok

Oliver 0429g - Why is informationCategory mandatory [answered]

Comment: (on informationCategory in ServiceCategorisation): why is this mandatory , it is not mentioned in the spec, if this needs to be mandatory, the spec needs to be adapted.

Answer: This is actually the field corresponding to the PCP information exchange areas as required by requirement SWIM-SERV-009 Service categories. So this is required by the spec.

Comment from Oliver: same as above, ok

Oliver 0429h - Why do types appear twice

Comment (on several rows, eg abbreviations): Why is that here and later on comes again?

Answer: Every type appears twice. Once where it is used (typing an attribute) and once where it is defined (defining its content in term of attributes or in terms of enumerated values).

  • Types definition for enumerated values appear in Code Lists walk-through page. So only their use appear in Schema walk-through.
  • Types definition with attributes are coloured in blue. The rule column is redundant with the rule in their use, and so appear simplified, such as (M). But this appears as an easy reminder.

Comment from Oliver: ok

Oliver 0429i - Mandatory attributes for an optional type

Comment (on attribute description within Concept type):  not ok , can not be mandatory , not in spec.

Answer: We all agree that providing this kind of information is optional. What the "Mandatory" expresses here is that, if you decided to describe a Concept (it's optional, it's your decision), then for each concept described the name and the description are mandatory attributes.

Comment from Oliver: is ok then, it's a conditional shall

Julia 28 Apr'20

SWIM-SERV-001 / informationService [answered]

Comment: - General question: In fact the document is a Service Description describing a SWIM (Information) Service, why not name it like this? I think it had been  Especially the relation between Service Description and Information Definition may be confusing when using the terms "service" and "information".

Answer:  "information service" is the term used systematically in ICAO SWIM documents. It is used to differentiate the services we discuss from other services such as air navigation services, air traffic services, MET services, etc. This term is in the serv desc spec terminology.

This term was not used much in SSCONE, as it is assumed that whenever we use the term "service" we mean "information service". 

SWIM-SERV-005 / 006 (serviceDescriptionIdentification + service identification) [answered]

Comment: - Why not name it as in Service Spec? --> Service Description Identification / Service Identification

- Food for thought: perhaps combine SWIM-SERV-005/006 within an element "identificationInformation" with sub-elements "serviceDescriptionIdentification(title, edition, referenceDate)" and "serviceIdentification(name, version, abstract)"? 

Answer: A better alignment would be beneficial.

SWIM-SERV-008 (Contact Info) [answered]

Comment: - REQ states: name, description and PoC (includes info like name, description/role, contact info)

- Food for thought: maybe just a mandatory element "contact info" would be sufficient. This can be anything varying from an email, postal address to a URL or anything applicable to the service provider without making the schema over-complicated

Answer: Indeed such a single string contactInfo could be sufficient.

As there is often the need to distinguish on human interface between the various kind of contact info, maybe list of contactInfo with a type and a string would fit the bill (with minItems=1  (wink)).  

SWIM-SERV-009 (geoExtent) [answered]

Comment: - Good idea to make it possible to give optional additional information about the data provided by the service. This makes sense for data that cover larger areas (like gridded data or polygons).

Answer: So a concrete proposal would be needed.

  • Make proposal

 Monica 28 Apr'20

try uploading table in Confluence [answered]

Comment: I had a look at the current version of the xls. As xls comments are hard to see I will put here the comments that I had (maybe we can upload the excel on Confluence and we can directly put the comments online- not sure if it is possible):

Answer: Tentative table in Confluence, see Schema walk-through.

add requirement link in Excel [answered]

Comment: Maybe an idea would be to add a link to an additional tab (in excel) where the Requirement's texts are transposed for quick readability reasons (This assumes that the walk-through will stay in Excel format). This would also be valid for the requirements of the Service Overview

Answer: In the Schema walk-through table under Confluence, the link can go directly the Handbook requirements.  

add column example [to be discussed]

Comment: In the “Guideline” Column there is a mix of indications and mentions, how about adding an extra column “Example” with the example from the Donlon file where appropriate? 

Answer: As examples can be long, it is probably better to keep them separate. To be discussed.

list in guidance

Comment: Where “Lists” are mentioned in the Guidance, maybe we can add where are these lists available (e.g. document, link etc.)

Answer: comment not clear to me...

tedious

Comment: More generally, I would add that for a “Walk-through” it is a quite tedious walk, but I do not really have a better suggestion than excel. Maybe people would use the file “when in doubt” situations.  

Answer: The walk-through doc, whatever its form, is a temporary doc just to help us in this task. The comment raises the questions on what we are aiming for as end products.

What are our end products? In what form? 

  • People maintaining the schema could use Schema evolution proposals, possibly complemented by the walk-through material.
  • People using the schema to write service descriptions, would need some kind of guidance material. This could be 
    • in the schema
    • in Confluence (eg in handbook)
    • in a separate doc (Word, Excel, ...)

Question: What's your opinion?

Received comments

Josef 27 Apr'20

Josef 0427a - geographically discoverable U-spaces services

 Comment [+]

I've raised this topic some time ago, but I have to admit I am not sure where it is best addressed, i.e. here or the Registry CCB. I think however since it's a schema issue it should rest with your group.

 There's a strong push to establish UTM systems and solutions both throughout Europe and the US. In fact one of the main projects I'm working on is to define and develop such services which follow the U-Space blueprint and we're doing our best to build connections and translate between the SWIM world and other de-facto standards (such as NASA TCL-4).

One of the main issues I'm facing is that for U-Space services to be discoverable in the service registry, I need to be able to look them up by geographic location, or by matching geometries (shapes, line segments, etc).

 Right now the schema supports either a FIR, Airport, or State coverage definition. This is unfortunately not sufficient in practice, as depending on the country, UTM responsibilities may well be split across multiple UTM Controllers covering parts of one FIR, or even custom geometries that denote areas of responsibility. Similary, some services have a coverage area imposed upon them by physics (be that sensor range, radio range, or other factors). I would love to, for example, evolve our UTM services we're deploying in Norway this year into fully compliant U-Space services over time, but the lookup in the service registry is not very useful if we are limited to FIR granularity.

 Can you give me some guidance where such a change would be able to be introduced? Is this a SWIM Governance issue? Could we add this in addition to the already defined geographic extent definitions, thus making this an optional level of detail that would not break the existing implementations?

Could we perhaps even have geographic search functionality in the eurocontrol SWIM registry?


Answer
:

  • For adding Geospatial capabilities to the Registry (or any other registry change), the best is to send a request to Roman. That will ensure we capture the need, and discuss this at the next CCB.
    But soon after that, we will probably need to define the geospatial attributes of a service, and fit that into the service schema. So back to SSCONE : ). Anyhow we should be able to reuse the work done for Geofencing within EUROCAE in that respect.
  • It is considered to add a field to include complementary text to define the geographical extent (eg thru a polygon).  


Julia 21 Apr'20

Julia 0421a - XML to JSON questions

Comment: Comments and questions within this Excel file: xml_vs_json_questions.xlsx

Answer: this file is being used as input for the walk-through.

Julia 6 Apr'20

In advance here are some major points I noticed while having a deeper look into the JSON schema files: ...

I think the kick-off meeting is a good opportunity to address those things get a better understanding on why some parts are realised the way they are.

Julia 0406a - schema more usable [noted]

Comment: Positive: enhancing the required option makes the schema more usable in terms of having some kind of template.

Noted.

Julia 0406b - clarification needed [answered]

Comment: The required statements differ not just in the main parts (serviceInterface, serviceInformationDescription,...) but also within the referenced sub-parts. This might be confusing.

Answer: Indeed, the rules for the 3 service types differ often on low level structures rather than just high level ones.

Julia 0406c - new schema enhancement [done]

Comment: In addition if you want to check wether a candidate is matured to a compliant description (because you don't know because of the reduced set of required properties) it is necessary to change the "serviceType" from SWIM_CANDIDATE to SWIM_COMPLIANT. Otherwise it will not be valid against the schema.

Resolution: resolved as "3d-Compliant+".

Julia 0406d - version of schema of services already in registry [answered]

Comment: It is unknown which to which JSON schema the description complies, especially which version. In this early stage there might be some further changes within the schema although there are already services in the registry compliant with an older schema version but not the new one. How is it intended to manage those changes and how does the registry handles that?

Answer: When the Registry CCB agrees to implement a newer version, ECTL will implement the change in the Registry and coordinate with the Service Owners to ensure the content is updated to reflect the new schema.

Julia 0406e - JSON ordering of fields [answered + addition]

Comment: The elements in the schema are ordered alphabetically, there is no logical order prescribed in the schema. So it is possible to change arrangements of the description for better readability.

Answer: In JSON the order of fields has no meaning. The order of fields has no impact on the import of JSON documents in the registry.
The alphabetical ordering of the schema is a feature of the tool generating the schema.
Some ordering make more sense for a human reader, and there may be value for harmonising the order of fields. This will be discussed during the walk-through. 

Addition on 20/04/20: a proposed ordering is made in file JSONv3_Assessment.xlsx.

Julia 0406f - JSON ordering in registry import [answered]

Comment: Can the registry handle different arrangements with importing Service Descriptions?

AnswerThe order of fields has no impact on the import of JSON documents in the registry.

Julia 0406g - JSON ordering in registry export [answered]

Comment: How about the export - is the original file provided or does the registry "re-parse" it (which means it may not be the original file)?

Answer: The registry generates a new JSON document out of the elements within the registry.
The registry produces a JSON file that validates with the schema. The registry orders elements consistently for every export. If the order needs to be updated, this can be managed as a change via the Registry CCB.

Julia 0406h - missing Filtering [answered]

Comment: Possibilites for statements regarding SWIM-SERV-024 (Filtering) are still missing

Answer: Correct. This is not conform to the Service Description specification.

Proposal for evolutionSchema evolution proposals#Filtering.

Julia 0406i - conforming to standard [answered]

Comment: Beside that I also noticed some other points which relate to specific elements in the JSON, for example the indication of standards and conforming to them (or to which degree?),...

Answer: Indeed a conformance statement in addition to a boolean can be confusing. 

  • Action: clarify in guideline.

Julia 0406j - why service behaviour in Interface? [answered]

Comment: ...  why the (service) behaviour (SWIM-SERV-025) should be stated within the serviceInterface ...

Answer: It often appears that behaviour is provided for closely related operations in the same interface. Would behaviour relate operations from different interface, feel free to describe it in one of the concerned interface.

  • Action put in guideline of behaviour
  • Action Pedro: check consequence if behaviour is moved up a level.

Julia 0406k - why email PoC not required? [answered]

Comment: ...  or that for a point of contact a name and description is required but no contact info like email.

Answer: It is effectively expected that contact info is provided. When email is provided, phoneNumber would not be mandatory, and vice-versa. And when a url is provided none of those would become mandatory. Implementing such logic in the schema would make it complex.

Proposal for evolutionSchema evolution proposals#ContactInfo.

Renato 05 Feb'20

Raised on page Assessment Schema 0.0.3 for Service Description.

Renato 0205a - missing "Filter" property [answered]

Comment: With reference to SWIM-SERV-024, both the SWIM Manual Vol 2 and PANS-IM-SWIM explicitly mention the need for the Filter property in a Service Description.

Answer: Indeed missing element to generate a service overview.

Renato 0205b - missing "Source of Information" property [answered]

Comment: There seems to be a missing property for "Source of Information" (again, mentioned in both the SWIM Manual Vol 2 and PANS-IM-SWIM)

Answer: Indeed missing element to generate a service overview.

Information

Pedro 14 Apr'20

Pedro 0414a - empty string treated as missing attribute [in schema .3e]

Comment: On the question "A simple question on how registry is checking mandatory fields of type string. Would an empty string satisfy?". The answer was "An empty string will be treated as a missing attribute."

Consequence: The check for mandatory fields of type string has to be adapted to required non-empty string. (eg with minLegth=1).

Pedro 0416a - date format [NEW schema vrs]

Comment: The expected format of the dateInOperation field is "dd/mm/yyyy".

Comment: The expected format of the dateInOperation field is "yyyy-mm-dd" (recommended standard format).

Consequence: The check for this field could be enhanced accordingly. Checking for pattern "^\d{4}\-(0?[1-9]|1[012])\-(0?[1-9]|[12][0-9]|3[01])$"

  • No labels