Serialization: lists of constants about spdx-3-model HOT 9 CLOSED

Profile identifiers are "structs" with just a name at the moment, not enums:

from spdx-3-model.

Although I would prefer the "conventional way", profiles are expected to get versioned, which is possible with objects without a breaking change:

  "profile": [
    {
      "name": "core",
      "version": "3.0.1"
    }
  ]

from spdx-3-model.

Every Element has its own specVersion; I'm not sure what applications would be expected to do with specVersion 3.2.0, profile core 3.1.2, software 3.0.5.

Of course lists are a general case, not just versioning. But if there were a use case for separately-versioned profiles they could be serialized as:

  "profile": {
    "core": "3.1.2",
    "software:": "3.0.5"
  }

The general case is described in #55 - do you serialize email headers with lists of repeated [ {name: x1, value: y1}, {name: x2, value: y2}, {...} ] pairs or with normal object properties {x1: y1, x2: y2, ...}?

from spdx-3-model.

Of course lists are a general case, not just versioning. But if there were a use case for separately-versioned profiles they could be serialized as:

yes, that would be possible. But that would still be a breaking change to your initial proposal. So, this does not help to avoid the breaking change in the "there might or might not be a future with individual versions"-Problem.

from spdx-3-model.

Every Element has its own specVersion; I'm not sure what applications would be expected to do with specVersion 3.2.0, profile core 3.1.2, software 3.0.5.

+1 from me, I also think that this is not a future to hope for. Maybe we can decide that it will not come. This would solve this thread.

from spdx-3-model.

Enumerated values are not properties. The SPDX model would need a breaking change to accommodate versioned profiles.

from spdx-3-model.

I'm not sure how to interpret that model notation - ProfileIdentifier is not enumerated on the diagram (my mistake), but it cannot be simultaneously a string and an object.

And irrespective of how the model is drawn, ProfileIdentifier is enumerated. It can't have any value ("Food" and "Aviation" are not valid ProfileIdentifier strings until the model includes Food and Aviation profiles). Whether they are drawn as vertical lists like RelationshipType and SoftwarePurpose or horizontal boxes like Licensing and Security, they aren't valid until the model says they exist.

from spdx-3-model.

Just found https://github.com/spdx/meetings/blob/f9e1bbe608d5f2b9b6f8bd9be26f9520339c22c5/tech/2022-10-04.md?plain=1#L55-L56:

• Proposal 2 - Remove the version from profiles, profiles will always be released in lock step with the SPDX spec. Implication, changing this would be a breaking change - so we are essentially deciding that profiles and specs will be release together until at least 4.0 (which allows breaking changes)
• Decision: Proposal 2 - remove version from profiles

the versions of profiles will not come back before 4.0. So my assumption in that case was wrong and I would obviously also choose the simple serialization.

from spdx-3-model.

Have submitted #249 this will be a bit more "automation friendly" than an arbitrary string, which is what it was set to, and should address @davaya comments about not having any value "Food", etc.
Will close this, but feel free to reopen if you disagree.

from spdx-3-model.