1 Pre Flight CS
** Authors:**
- Leif Johansson leifj@siros.org
1.1 Context
The consortium sometimes requires fast and lightweight conformance specifications in order to start testing. For some areas the standardization situation is pretty clear cut and testing can proceed with a minimal “pre-flight” CS that references existing standards.
The expectation is that the result if testing is fed back into the CS process in WP4 so that a better and more informed CS can be produced as the result of the first round of testing.
1.2 Decision
The consortium will support the publication of pre-flight CS documents. Such documents are characterized by essentially being references to existing standards and possibly some profile. A pre-flight CS is not meant to be normative and should only be used when the standards situation is clear but there is a lack of testing. The pre-flight CS is meant to resolve a catch-22 where WP4 is waiting on testing to complete a CS but the testing needs a CS to begin.
1.3 Consequences
1.3.1 What becomes easier?
This decision enables faster progress on emerging standards across the EUDI ecosystem.
1.3.2 What becomes more difficult?
Feedback from the testing phase is necessary to complete the work on a proper CS for the ecosystem.
1.3.3 How do we address the risks introduced by this change?
A structured report-back process from the testing in other WPs to inform the next version of the CS in question.