Punch List: Element

[iamwillbar]

This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:

• Should we take all creation related elements and put in a separate class? Problem to solve at logical model level - there may be a set of elements created at same time with same tool. Concern about serialization compactness. Seems simpler to have Creation Info.
• Should we be describing creation as an event?
• Is created data type to be made up?
• What is the impact of element created date on determinism for reproducible builds? What are the use cases for created date?
• What is the precise type of sem-ver?
• For profile, if a collection has one profile, but element only applies to a base, do you put integrity on it? Alternately element has list of multiple profile, vs. collection has multiple elements with different profiles?
• Does data license need to be constrained to CC0?

[davaya]

Discussion:

• Each Element is immutable, which requires the existence of an event at which it stops being designed/modifiable.
• Various names for that event ("published", "minted", "created", "serialized", "signed", etc.) have been discussed.
• An Element's creation/immutability event can be no later than the first time it is serialized into a data unit ("document"). An Element's deserialized value must be identical across all documents in which it appears.
• Multiple elements serialized into a single document can have the same creation info as the document, improving compactness.
• Multiple elements serialized into a single document can have creation info earlier than the document, at the expense of compactness.

Position:

• The logical model should have a CreationInfo / Created data type referenced by a single "created" property.
• A transition-to-immutability event must exist.
• Creation is the straightforward word to use for that event, with the explanation that creation is the point at which the Element's id becomes reserved and its property values cannot be changed.
• Minting is a less overloaded term than creation and may be helpful when describing the creation event.

[iamwillbar]

Arguments regarding separating creation properties:

• Against separating them: Atomicity - too easy to communicate them independently and risk losing them and breaking integrity of the element
  • Counter point: Possible with other properties, not unique to creation.
  • Counter point: Combining into a class helps preserve atomicity by bundling creation date with creation by.
  • Counter point: We can enforce serialization of properties
  • Counter counter point: Those properties aren't integral to the element.

Point of confusion:

• Separating creation properties as a single instance class (Sean's preference), multi-instance class (Gary's preference), or element (no one desired this, and it could have circular dependency issues).

[davaya]

The logical model Element class currently has two properties: "created" of type DateTime and "createdBy" of type Identity[1..*]. The proposal is to combine them into a single property "created" of type "Created", where the Created type has properties "when" of type DateTime and "by" of type Identity[1..*]. Identity needs a lot of work*, but that's a separate topic.

I'm confused about the meaning of "single/multiple instance class", but surely there is a modeling approach that supports a Coordinate class. Regardless of whether Elements have "latitude" and "longitude" properties that could be replaced by a single "location" property of type Coordinate, or only a subset of Element types need a location property, it must be possible to combine two atomically-linked properties into a single Coordinate type without breaking the model.

Created is exactly the same - the "who" and "when" properties are an atomic pair, and the atomic Created type can be a property of one or more other types.

---

• Identity: IMO it's challenging to believe that an Artifact could have an originator that is one or more Tools and Organizations and Persons acting independently (e.g., as separate co-signers). But converting one or more Tools and Organizations and Persons into a single actor (signer) acting jointly (e.g., as a set of participants) to originate an artifact will require lots of discussion.

A first step would be to define an Actor type that is the single originator (holder of a signing key) of an artifact or creator of an element. Defining the properties of Actor can be worked later.

[iamwillbar]

@iamwillbar to write up thoughts on data license.

[swinslow]

@iamwillbar Looking back at this thread, and the comment about data license / CC0 -- if you're still looking into this, you may want to look at the old thread at spdx/spdx-spec#159 (and other details linked from there).

If there's a proposal to change and move away from the CC0-1.0 constraint for data license for SPDX data, I'd encourage (1) taking a look at the questions in that thread that the legal team folks were asking for input about; and (2) submitting it as a Change Proposal so that there's greater visibility across the SPDX teams for discussion.

[goneall]

What is the impact of element created date on determinism for reproducible builds? What are the use cases for created date?

There is a separate issue #214 tracking this

[kestewart]

@iamwillbar - am closing this issue (as the only outstanding one, is now being tracked by #214 . Please reopen if you disagree.