On Tue, Apr 20, 2021 at 4:22 PM William Bartholomew <[email protected]>
wrote:
> Having one way to reference "things" within and across SPDX documents
> (which is Document Namespace + SPDXID) (which is effectively the main
> capability that Element brings) establishes a "contract" that any element
> in SPDX (identities, artifacts, defects, etc.) can use to consistently
> refer to elements. Having each entity define its own method of referencing
> elements will lead to a lot of inconsistency and subsequent confusion. With
> your point above of not needing to ensure that one person has one
> identifier it also frees us from needing to identify the perfect primary
> key for an identity, for example, in your scanner example if we decide that
> email address is the primary key what would the scanner do if it knows the
> name of an entity but not its email address? Email address is optional in
> our model and not a good candidate for a primary key, not to mention I'd
> say that most of us have more than one email address and aren't necessarily
> consistent about which ones we use where,
>
My concern was with how one application interfaces with another, i.e. the
serialization of the model and references to Elements within a Document. I
agree that forming external references as URIs DocumentNamespace/IdString
is a good approach.
If the diagram can be interpreted as "Document is a set of Elements, each
of which has a flat id":
Document = {
Element0, // Document
Element1, // Artifact1
Element2, // Artifact2
...
Element43, // Identity1
Element44, // Identity2
...
Element79, // Relationship1
Element80, // Relationship2
,,,
Element104, // Annotation1
Element105 // Annotation2
}
Element = {
id, name, summary, description, comment, {Document-only attributes}
ExternalReference [0..*],
Extension [0..*],
IntegrityMethod [0..*]
}
where the complete list of Element types is [Document, Artifact, Identity,
Relationship, Annotation], then we are on the same page.
But it is not obvious from the diagram that that is the case. My concern
is that the diagram could be interpreted in such a way as to generate
recursive Element structures (i.e. references that are paths of indefinite
length "Namespace/x/y/z/..."), but that may be just my lack of
understanding of the modeling methodology. Once you explain that
references are Namespace+IdString (and assuming IdString is flat and
identifies the type of Element), things start clicking into place.
Regards,
Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4044): https://lists.spdx.org/g/Spdx-tech/message/4044
Mute This Topic: https://lists.spdx.org/mt/82242865/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
