I went through some of the modeling documents you provided on Google Drive.
Overall, the model looks good and I appreciate how well it aligns with the SPDX model. There are a few understandable differences in terms, but those are mostly in abstract classes that would not be represented in a concrete Document.
I do have a couple of suggestions based on our experience in the SPDX modeling:
- Support for Multiple “Items” within a Document:
The current SBOM mobile has a 1:1 relationship between a Document and a Package. I would propose a structure which allows multiple “Items” to be represented within a single document. An Item would be a superclass
of both Package and File. A Document would have a 1 to many relationship to Items. Item would be a subclass of Element. This would be similar to the SpdxItem class in the
SPDX Model. Note that in the SPDX model, SpdxItems are referenced by the SpdxDocument through the relationship properties in the SpdxElement superclass. Another note on SpdxItem – it currently
contains a number of required licensing related properties. In the 3.0 spec, these properties will most likely become optional and some additional security related properties added to enable support of security related use cases without the burden of adding
It turns out version 1.0 of SPDX had a 1:1 relationship between a Document and a Package. As we gained experience in using the SPDX Document, we found several use cases which required a more flexible structure.
As an example, we wanted to have an SPDX Document which just described a patch file which patched a package. The package definition was external to the document. Describing a single file in an SPDX Document wasn’t possible in our 1.0 version. Another common
use case was wanting to describe the composition of a package within the same document. This required multiple packages to be represented within the same document. Note that the above examples would likely be just as important in a security related use case
as it would be to a copyright license related use case.
- Move relationships from the Document to Element:
If the above proposed change is made and there are multiple “Items” represented within a Document, providing relationships within the document itself would be important to support several of the use cases. Moving
relationships to Element would allow relationships between Packages, Files and Documents.
I will be traveling starting tomorrow, but I plan on checking emails approximately daily and would be happy to continue a dialog via email on the model.
Also – let me know if you would like to move this discussion to one of the documents in Google Docs.
Source Auditor Inc.
Email: CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which
it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and destroy any copies of this information.