Implements conditional subschemas based on component type

[stevespringett]

Implements and closes #638

[Copilot]

Pull request overview

This PR implements conditional subschemas for component properties based on component type, as specified in issue #638. The changes enforce that certain properties (modelCard, data, cryptoProperties) can only be used with specific component types.

Changes:

• Removed modelCard, data, and cryptoProperties from the main component properties section
• Added conditional subschemas using allOf with if-then-else logic to enforce type-specific property usage
• Added a new conditional requirement for hardware components to prevent swid and purl specification

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Mehrn0ush]

Hi @stevespringett — quick catch on “Version Range Requirement” (around line 281), unless I’m misunderstanding the intent:

Right now the rule triggers on the presence of versionRange, and the then clause only constrains isExternal to be true if isExternal is present. Since isExternal is not required there, an object can still include versionRange while omitting isExternal, and it will pass validation.

If the intent is “versionRange may only be used when isExternal is true” (as the versionRange field description suggests), a more direct pattern would be:

{
  "if": { "required": ["versionRange"] },
  "then": {
    "properties": { "isExternal": { "const": true } },
    "required": ["isExternal"]
  }
}

One small wording consistency nit: the Version Range rule description currently reads “versionRange must not be present when isExternal is false”, while the versionRange field description says “May only be used if isExternal is true.” These are closely related, but it might be worth aligning the phrasing so the intent is unambiguous (and easier to carry into spec text later).

[stevespringett]

@Mehrn0ush thank you for the thorough review.

Right now the rule triggers on the presence of versionRange, and the then clause only constrains isExternal to be true if isExternal is present. Since isExternal is not required there, an object can still include versionRange while omitting isExternal, and it will pass validation.

I believe that is accurate and captures the current behavior in v1.7

If the intent is “versionRange may only be used when isExternal is true” (as the versionRange field description suggests), a more direct pattern would be:

@jkowalleck I know you worked on this. What are your thoughts. I attempted to keep the existing logic in place - and I think I have.

One small wording consistency nit: the Version Range rule description currently reads “versionRange must not be present when isExternal is false”, while the versionRange field description says “May only be used if isExternal is true.” These are closely related, but it might be worth aligning the phrasing so the intent is unambiguous (and easier to carry into spec text later).

I'm open to improving the wording. Suggestions.

As far as the design goes. This issue passes the public RFC comment period.

[stevespringett]

Actually, this was a defect, so no comment period was necessary.

[Mehrn0ush]

I'm open to improving the wording. Suggestions.

Thanks — on wording, I think it really depends on whether we’re just clarifying the text or actually fixing the defect.

If we fix the defect and require isExternal whenever versionRange is present (i.e., versionRange is only valid with isExternal: true), then the current phrasing works well and could even be made more direct:

• Rule: “versionRange may only be used when isExternal is true.”
• Field: “May only be used if .isExternal is set to true.”

If, however, we keep the current behavior (where versionRange can appear without isExternal), then the wording should probably be softened to avoid implying stricter validation than the schema enforces, e.g.:

• “If versionRange is specified and isExternal is present, isExternal MUST be true.”

Happy to go with whichever direction makes the most sense here.