The yaml file (e.g., scs-compatible-iaas.yaml is not intelligible unless you study the docs very closely; this is alleviated by the automatically created markdown representation, e.g. scs-compatible-iaas, but this translation procedure needs to be maintained, and it is not guaranteed to be 100 % faithful.
The yaml file contains many details that are not relevant for standardization; it has been reorganized multiple times (see scs-0003-v1 git history) and will be reorganized more, without (functionally) affecting standardization or certification.
Therefore a regular standard should be created for each scope; this way, we can inherit lifecycle and versioning (which was duplicated for the yaml file!)
The yaml file will probably still be needed for compliance checks, but it will be an implementation detail that can be changed more easily; relevant for certain people, but not for standardization efforts per se.
The yaml file (e.g., scs-compatible-iaas.yaml is not intelligible unless you study the docs very closely; this is alleviated by the automatically created markdown representation, e.g. scs-compatible-iaas, but this translation procedure needs to be maintained, and it is not guaranteed to be 100 % faithful.
The yaml file contains many details that are not relevant for standardization; it has been reorganized multiple times (see scs-0003-v1 git history) and will be reorganized more, without (functionally) affecting standardization or certification.
Therefore a regular standard should be created for each scope; this way, we can inherit lifecycle and versioning (which was duplicated for the yaml file!)
The yaml file will probably still be needed for compliance checks, but it will be an implementation detail that can be changed more easily; relevant for certain people, but not for standardization efforts per se.