Missing properties cccev:expectedDataType, cccev:expectedValue, cccev:maximumValue, cccev:minimumValue etc.

[jimjyang]

The class CriterionRequirement in CCCEV v.1 had properties expectedDataType, expectedValue, maximumValue, minimumValue etc., which are necessary to specify e.g. the requirement "age (positiveInteger) >= 20" machin-readably.

The class CriterionRequirement in CCCEV v.1 is split into the classes Requirement, Information Requirement and Constraint in CCCEV v.2, without explicitly mentioning where the abovementioned (and several other) properties of CriterionRequirement are in v.2.

Our questions are:

1. Where are the properties of CriterionRequirement in CCCEV v.1 now in CCCEV v.2? If they are intentionally omitted, why? As exemplified above, they are necessary in order to have machin-readable specifications of requirements and they should be standardized at the EU level.
2. The class CriterionRequirement is deprecated, are the properties cccev:expectedDataType (with cccev namespace) etc. also deprecated? Or, is it still allowed and advisable to use them (with new domains), e.g. in connection to (national application profiles of) CPSV-AP?

[bertvannuffelen]

@jimjyang indeed there has been a major shift between CCCEV 1.0 and CCCEV 2.0.

The listed original CCCEV 1.0 properties have not been reused as their semantics are semantically conflicting with CCCEV 2.0. In order to have CCCEV 1.0 implementations not to face with a forced semantical switch of the properties they are kept with the original semantics in the deprecated CCCEV 1.0.

Nevertheless there is in CCCEV 2.0 an alternative approach that facilitates the same use case.
Namely the whole area of the termInformation Concept.
An Information Concept is a piece of information that plays a role in the exchange process between the Requirement and the Evidence.
The notion of expected value part of this class. And that value allows more than min/max expressions.

I hope this clarifies how the usecases of version 1.0 are included in version 2.0.

[jimjyang]

@bertvannuffelen

Yes, in the meantime, we have already tried to model requirements using the classes Information Concept, Constraint, ... (conf. the explanation - though in Norwegian only - on how to model a requirement, in our draft version of CPSV-AP-NO)

[bertvannuffelen]

@jimjyang thanks for the pointer to your implementation guide.