search

spdx / spdx-3-model

Other
64 stars 41 forks source link

Expressing conformance constraints #522

Open zvr opened 8 months ago

zvr commented 8 months ago

Besides the purely "syntax" constraints (which property can appear in which class, for example, or even the cardinality of properties), it seems that there is need to express more "semantic" constraints.

This issue should be the place to discuss them, understand the requirements, and come up with a way to have them expresses in the model.

zvr commented 8 months ago

It should be pointed out that there is always the option of simply describing the restrictions in text!

The SPDXv2 specification has a number of such restrictions, simply expressed in the text.

We should try to have a balance between expressing all the restrictions formally so that they can be checked automatically and expressing them in understandable text.

zvr commented 8 months ago

From what I remember, there has already been mention of:

  1. making optional properties mandatory
  2. requiring Relationship element to exist, with a specific relationshipType and the from (or to) pointing to an element
  3. same as (2) above, but the relationshipType being one of a set of valid values
zvr commented 8 months ago

1. making optional properties mandatory In general, changing cardinality of a property in a parent class. Example: /Software/File needs to specify that the property name of the ancestor class /Core/Element has to exist.

Solution: have an External properties restrictions restriction, providing fully qualified class name, property name, and characteristic to be changed (see example)

goneall commented 8 months ago

Note the related issue https://github.com/spdx/spdx-3-model/issues/463 requesting specific relationship restrictions.

Also note the specific syntax proposal: https://github.com/spdx/spdx-3-model/issues/462#issuecomment-1714744171

goneall commented 6 months ago

Based on prior tech call decisions, we will document the constraints in the profile markdown document for RC2.

It is still open on when / if we will translate the constraints into a SHACL/OWL file.

Moving this issue from RC2 to 3.0 release.

jeff-schutt commented 4 months ago

Here's a scenario that was uncovered during the security team meeting and may help clarify what's desired with the broader discussion/issue. This is a specific example of the third scenario described in https://github.com/spdx/spdx-3-model/issues/522#issuecomment-1773730473

Whereas they were present in prior diagrams, the most recent security model diagram has two classes without any properties listed. Both markdown files 1 model/Security/Classes/VexFixedVulnAssessmentRelationship.md 2 model/Security/Classes/VexUnderInvestigationVulnAssessmentRelationship.md ...document Constraints as restrictions in the text Description (as proposed above https://github.com/spdx/spdx-3-model/issues/522#issuecomment-1773729525) because the constraints can't currently be modeled or parsed.

The desire is to list the relationshipType property in each of the above markdown files and to constrain/restrict each of these markdown files to only one applicable value (fixedIn or underInvestigationFor) from the more expansive list of entries in model/Core/Vocabularies/RelationshipType.md.

goneall commented 3 months ago

On the SPDX Tech call - agreed to just use documentation in 3.0, we could add the validation in 3.1