Ongoing discussions within the SWIM communities of interest
Ongoing discussions within the SWIM communities of interest
Object under Assessment
SWIMRegistrySchema_v0.0.3.json, as used by the SWIM Registry application for uploading / downloading Registry Entries.
|conformance to SD spec||assess whether the schema allows to produce a SD satisfying the requirements of the SD spec|
|trace to SD spec||map between spec requirements and schema fields (as the structure and naming may diverge from the spec or the supporting material)|
|aligment with supporting material||assess how far the schema allows to satisfy the supporting material in the SD handbook|
Note that alignment with SIR and supporting material have not started yet.
|use for SD validation|
Elements in the Schema are optional, so that the Schema cannot be used to validate a JSON doc (almost any JSON doc is valid).
The SWIM Registry validates a JSON doc with business rules within the application.
|structure, grouping, naming|
Mapping between schema structure and req could be improved.
There's a need to explain and/or restructure.
Unclear why some arrays have minItems = 1 for an optional field. When not filled in (yet) the field has to be removed, instead of remaining with an empty array.
The use of external documents need be clarified. In general and in relation to other fields (eg model, behaviour, information definition).
Can some of these documents be a part of the service description?
|diagrams||How are diagrams be provided? Only through an external document?|
Overall Assessment - NOT CONFORM
|req count||status||status description|
|1||requirement not satisfied|
|1||unclear status, need more info|
|1||tbd||not assessed yet|
|Requirement||level||status||reference / comment|
|SWIM-SERV-001 Description coverage|
Map: field informationService is the entry point. The field is not mapped to the requirement.
|SWIM-SERV-002 Description language|
|tbd||(not assessed yet) The checking will be about the use of UK English within the schema, in particular for field names and guidance text.|
|SWIM-SERV-003 Define abbreviations|
Map: fields name, description in abbreviations. Fields map to requirement (except description).
|SWIM-SERV-004 Use standard abbreviations|
(no assessment to be done)
|SWIM-SERV-005 Description identification|
Map: fields Title, Edition, ReferenceDate in ServiceDescriptionIdentification. Fields map to requirement.
|SWIM-SERV-006 Service identification|
|Map: fields name and version within Information Service. Fields map to req.|
|SWIM-SERV-007 Service abstract|
|Map: field abstract within Information Service. Field maps to req.|
|SWIM-SERV-008 Service provider|
Map: fields provider, providerDescription, pointsOfContact within ServiceProvision. Fields map to req.
Within Point of Contact:
Within Service Provision, there are additional fields with unclear use.
|SWIM-SERV-009 Service categories|
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).
|SWIM-SERV-010 Service standard reference|
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
|SWIM-SERV-011 Operational needs|
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.
|SWIM-SERV-012 Service functionality|
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.
|SWIM-SERV-013 Access and use conditions|
Map: fields type, name description within accessAndUseCondition. Fields map to req, except for name and type.
|SWIM-SERV-014 Quality of service|
Map: fields name, description within qualityOfService. Fields map to req.
|SWIM-SERV-015 Technical constraint|
|Map: fields name, description within technicalConstraint. Fields map to req.|
|Service Interface Requirements|
|SWIM-SERV-016 Service interfaces|
|Map: fields name, description, interfaceProvisionSide, and endPoint.address within serviceInterface. Fields map to req.|
|SWIM-SERV-017 Message exchange pattern|
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)
|SWIM-SERV-018 TI Profile and bindings|
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?
|SWIM-SERV-019 Protocols and data format|
About Data format part
About Protocol part
|SWIM-SERV-020 Machine-readable interface|
Map: fields title, version, description,reference, documentType within serviceDocument (within serviceDescriptionReference) with type=MACHINE_READABLE_SERVICE_DESCRIPTION. Felds do not map to req.
|SWIM-SERV-021 Service operations|
|Map: fields name, description, precondition, operationMessage, etc within operation (within Interface). Including as well message details. Fields map only partially to req.|
|SWIM-SERV-022 Information definition|
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.
|SWIM-SERV-023 AIRM conformance|
Map: fields airmConformant, airmVersion within informationDefinition. Fields map to req.
|SWIM-SERV-024 Filter capabilities|
TBD (no reference to req SWIM_SERV-024)
If needed the fields name and description within concepts (within serviceGeneralDescription) can be used.
|SWIM-SERV-025 Service behaviour|
Map: fields name, description within behaviour (within serviceInterface). Fields map to req.
There is as well a document type SERVICE_BEHAVIOUR_DESCRIPTION.
|SWIM-SERV-026 Model view|
|Map: fields title, version, description,reference, documentType within serviceDocument (within serviceDescriptionReference) with type=SERVICE_MODEL. Fields do not map to req.|
|SWIM-SERV-027 Service validation|
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 .
|SWIM-SERV-028 Service monitoring|
|Map: field monitoingDescription within serviceMonitoring (within servieTechnicalDescription). Reference Field maps to req.|
|SWIM-SERV-029 Examples of code|
|Map: fields title, version, description,reference, documentType within serviceDocument (within serviceDescriptionReference) with type=CODE_EXAMPLE. Fields do not map to req.|