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.