You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
11
+
12
+
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.
13
+
14
+
## Decision
15
+
16
+
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.
17
+
18
+
## Consequences
19
+
20
+
### What becomes easier?
21
+
22
+
This decision enables faster progress on emerging standards across the EUDI ecosystem.
23
+
24
+
### What becomes more difficult?
25
+
26
+
Feedback from the testing phase is necessary to complete the work on a proper CS for the ecosystem.
27
+
28
+
### How do we address the risks introduced by this change?
29
+
30
+
A structured report-back process from the testing in other WPs to inform the next version of the CS in question.
0 commit comments