A first somewhat coherent but still very rough draft of a Conformance Guide is now up. This is the README document for the conformance specifications it is based on the older conformance draft and newer content from @pablo .
All feedback welcome.
1 Like
Great start and very useful. I do think though if conformance assessment is to be considered we need to make sure we express archetype specifications in a manner which supports conformance assessment by making it clear what is shall, should, may etc. There may be a number of technical shalls, and the use of should is highly relevant i.e. if you are going to do X then it is to be done this way… may being totally optional. There are many archetypes which are described with less specific terms such as can, and such terms are not clearly defined. It is vital that conformance is not only considered from the technical use perspective but also from the content that is being created and the ability of that content to conform to the shared international vision.
Agree. This is a WIP, and we have to do more on content conformance, which is the part that brings in archetypes. Yesterday I upgraded this table in the Guide - you will see a row for ‘Semantic Conformance’ (I think I may rename this to ‘Content Conformance’).
I’ve also just incorporated @pablo 's current set of content conformance test cases, based on specific Templates - see here in the Test Schedule. These TCs have to have identifiers added. They currently (as far as I can see) all operate on a ‘MUST’ level of conformance, i.e. the idea is that the server cannot permit invalid data (data not conforming to its archetypes) to be committed.
If we want something more nuanced than that, I think we’d need to get a better idea of when ‘should’ etc could be used - maybe an example?
1 Like