In preparation for the Examples discussion, proponents of nested
serializations should provide two example Payloads:
1) a transfer unit that carries two SBOMs urn:spdx.dev:null-sbom-a and
urn:spdx.dev:null-sbom-b.
2) a transfer unit that carries two SBOMs urn:spdx.dev:null-sbom-a and
urn:spdx.dev:null-sbom-b where SBOM B is included in SBOM A, e.g.:
{
"type": "SBOM",
"id": "urn:spdx.dev:null-sbom-a",
<... 5 creation properties ...>,
"elements": [
"urn:spdx.dev:iamwillbar",
"urn:spdx.dev:spdx-tools-3.0.1",
"urn:spdx.dev:null-sbom-b"
]
}
The nested serialized data examples must illustrate how these cases are
handled when, for example, both SBOM A and SBOM B contain some of the same
elements, e.g. the Person and/or Package elements from the current SBOM
example.
Regards,
David
On Wed, Sep 21, 2022 at 2:29 PM David Kemp via lists.spdx.org <dk190a=
[email protected]> wrote:
> We have already agreed that some use cases, including streaming, involve
> sending individual Elements. The logical model currently includes example
> values, but none of them include individual elements. The "Minimal Example
> Element (JSON)" data is not an Element - it has a type of Person but it
> does not include any Person values. This illustrates that examples are
> necessary to refine the model - it currently has ExternalIdentifier and
> ExternalReference structs that are supposedly used in Actor and/or
> Identity, but the examples don't use them. (IMO, Actor should have a
> required "identifier" property with the value "urn:spdx:dev:iamwillbar" but
> no locator as included in ExternalIdentifier.)
>
> A Minimal SBOM example is also needed that shows the value of a single
> SBOM Element without the values of any other elements; e.g.
>
> {
>> "type": "SBOM",
>> "id": "urn:spdx.dev:null-sbom",
>> <... 5 creation properties ...>,
>> "elements": [
>> "urn:spdx.dev:iamwillbar",
>> "urn:spdx.dev:spdx-tools-3.0.1"
>> ]
>> }
>
>
> This single SBOM element has only the values of the SBOM element, not the
> values of other elements that it references. It doesn't make sense to
> include a hash verifiedUsing because a consumer computes and verifies a
> hash of the element against the value included in a reference to the
> element. It could include a creator signature verifiedUsing, but a minimal
> example probably wouldn't use per-element signatures. There are no
> rootElements or externalMap properties in a single element; those are
> properties of the SpdxDocument element.
>
> The Person element could replace the existing Minimal Single Element since
> it does include externalIdentifiers, but it demonstrates that the model is
> missing both ExternalIdentifierType and an "authority" property as shown in
> the example, and the property name is "externalIdentifierType" or should be
> changed to just "type" to match the example. ExternalIdentifierType would
> be capitalized and include at least the values "EMAIL_ADDRESS" and
> "ACCOUNT".
>
> The Package example needs serious rework - "externalIdentifiers" would
> have either a "type" or "externalIdentifierType", and
> ExternalIdentifierType would need EXTERNAL_REFERENCE value, and in general
> the structure of an ExternalIdentifier that contains an ExternalReference
> must be clarified.
>
> The verifiedUsing property makes sense for Package because the package
> artifact (a sequence of bytes) can be hashed. This points out the need to
> reconcile the meaning of the verifiedUsing property, it is the hash or
> signature of artifact bytes, not a signature of serialized element bytes.
>
> In short, the Examples must include the values of three individual
> elements, a Person, a Package, and an SBOM, serialized in at least JSON,
> but it would be useful to have serialized values of the identical three
> elements in other formats as well (in accompanying files, not on the model
> diagram).
>
> Regards,
> David
>
> On Sat, Sep 17, 2022 at 12:37 PM David Kemp via lists.spdx.org <dk190a=
> [email protected]> wrote:
>
>> One thing that still needs to be decided is whether or in how much detail
>> the logical model goes to define the Payload. This requires agreeing on
>> the answers to two questions:
>>
>> 1 - True or False: *Elements stand alone, with a unique SPDXID and a
>> value that doesn't depend on any other element.*
>> Elements can be visualized as marbles, where each marble has its own
>> SPDXID, and 0..* IRIs that are the SPDXIDs of other marbles.
>>
>> 2 - True or False: *The logical value of an element is not affected by
>> serialization.*
>> In an element store (logical graph), an element 0 with 1..* IRIs of other
>> elements always works correctly without regard to how or if elements 0 and
>> 1..* may have been serialized.
>>
>> If these are true, then elements are marbles, marbles can be placed in a
>> cup, and a cup is not a marble. The cup is a Payload, and like a cup of
>> marbles or a tarfile of serialized elements, the Payload can contain any
>> combination of elements without regard to their types or any edges between
>> them.
>>
>> The SpdxDocument element describes a Payload. Because a marble is not a
>> cup, an SpdxDocument element is not a Payload. The Payload is a sequence
>> of bytes that carry any combination of 1..* elements without regard to
>> serialization format and without any alteration of their logical values.
>> The marbles in the picture can pulled apart, put into any combination of
>> one or more Payloads with the same or different serialization formats, then
>> unambiguously deserialized and reassembled into the identical logical graph
>> as before.
>>
>> If we want to define Payload in the logical model, then it is a datatype
>> that goes with other datatypes on the right side of the diagram, and it is
>> modeled as an OWL/RDF collection - a first/next/nil structure, not what
>> SPDX calls a "collection" which is an OWL/RDF container.
>>
>> Regards,
>> David
>>
>>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4790): https://lists.spdx.org/g/Spdx-tech/message/4790
Mute This Topic: https://lists.spdx.org/mt/93746148/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
