M

Map: field informationService is the entry point. The field is not mapped to the requirement.

M

M

Map: fields name, description in abbreviations. Fields map to requirement (except description).

R

(no assessment to be done)

M

Map: fields Title, Edition, ReferenceDate in ServiceDescriptionIdentification. Fields map to requirement.

M

M

M

Map: fields provider, providerDescription, pointsOfContact within ServiceProvision. Fields map to req.

Within Point of Contact:

• unclear how to put a URL or postal address.
• Consider rename field description to role, in alignment with req.

Within Service Provision, there are additional fields with unclear use.

• field Service Support "Provision of material and guidance necessary for the use of the information service".
  • It is unclear what this is supposed to be containing.
  • Is this related to Service Overview's field Support Availability "An overview of whether any service support may be offered to consumers"?
  • If not clarified, consider removing.
• field Date in Operation:
  • guidance needs to be more specific if this is for the service or the service version.
  • for a date in the future it is unclear what happens when the date is reached.
• field Provider Type:
  • Use not clear. Should this be considered as a service category?

M

Map: field informationCategory within serviceCategorisation. No definition. No map to req.

Add description to field informationCategory and trace it to req.

Additional categories inline with SWIM Gov proposal : businessActivityType, geographicalCategorisation, intendedConsumer, lifecycleStage (with values Prospective, Operational, Retired).

category serviceType

• this category mixes the notions Service Instance vs Service Definition with the notions about SWIM compliance (SWIM_COMPLIANT and SWIM_CANDIDATE).
• Consider separating the 2 aspects. Possibly only the first one should be kept in the Schema: serviceType with values SERVICE INSTANCE and SERVICE DEFINITION.

category applicationMessageExchangePattern

• this is new as a category; refers correctly to req 017 (see below).

M

Map: Covered , with fields title, version, description, reference, isConformant, conformantStatement within the concept of implementedStandard with code serviceStandardType = SERVICE_STANDARD (the whole being in serviceDescriptionReferences). Most fields do not map to req.

Consider clarifying the usage

• when not adhering to a service standard (an explicit statement is epexted)
• for other cases than SERVICE_STANDARD

M

Map fields name and description within operationalNeed. Fields map to req, except for name.

Note: No specific fields for the IERs. these are treated as other operational needs.

M

Map: fields name, description, realWorldEffect within functionality. Fields map to req, except for name.

Consider renaming description to function for a better alignment to req.

M

Map: fields type, name description within accessAndUseCondition. Fields map to req, except for name and type.

M

Map: fields name, description within qualityOfService. Fields map to req.

M Cond

M

M

Map: field applicationMessageExchangePattern within serviceCategorisation. Field maps to req.

The MEP identification document would benefit from being aligned to values of the CodeApplicationMessageExchangeType (eg on "ONE_WAY", probably more)

M

Map: fields serviceInterfaceBinding, networkInterfaceBinding, interfaceBindingDescription within serviceInterface. Fields map to req except for netwrok and interface.

To be clarified. The TI Profile and its version seem only mentioned through CodeServiceInterfaceBindingType. What about implemented standard mentioning TI Profile?

M

About Data format part

• Map: fields name, schemaLanguage, reference within exchnageSchema (within serviceInformationDescription).

About Protocol part

• Map: field interfaceBindingDescription within serviceInterface. Field traces to req.
• Not sure this helps to satisfy the requirement.

M Cond

Map: fields title, version, description,reference, documentType within serviceDocument (within serviceDescriptionReference) with type=MACHINE_READABLE_SERVICE_DESCRIPTION. Felds do not map to req.

M

M

Map: fields name, description, within informationDefinition. Fields map to req. And fields title, version, description,reference, documentType within serviceDocument (within serviceDescriptionReference) with type=INFORMATION_DEFINITION. Fields do not map to req.

Note: this implies that the information definition is a separate document.

M

Map: fields airmConformant, airmVersion within informationDefinition. Fields map to req.

M

TBD (no reference to req SWIM_SERV-024)

If needed the fields name and description within concepts (within serviceGeneralDescription) can be used.

M

Map: fields name, description within behaviour (within serviceInterface). Fields map to req.

There is as well a document type SERVICE_BEHAVIOUR_DESCRIPTION.

R

M

Map: field description (and type) within validation (within serviceGeneralDescription). Field maps to req. There's as well an external document with type SERVICE_VALIDATION_REPORT.

Clarifications needed to indicate to indicate that no validation has been performed. Consider extend the code CodeServiceValidationType with value NO_VALIDATION .

M Cond

R