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 (#4789): https://lists.spdx.org/g/Spdx-tech/message/4789
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]]
-=-=-=-=-=-=-=-=-=-=-=-
