Wouldn't the root element list be in a known location near the beginning?
rootElements is a property on Document which is at the root of the file,
for example:
document:
rootElements:
- namespace#id1
- namespace#id2
I am a little concerned about us re-opening some of these things,
rootElements have been in the SPDX 3.0 model since early February.
Comparing the logic for finding SBOMs between the two implementations:
* rootElements approach: Navigate to document.rootElements, loop through
each entry, load the elements it references filtering to those of type SBOM.
* relationships approach: Navigate to document.relationships, loop through
each entry that has relationship type DESCRIBES, filter to those where the
from is the document and the to is of type SBOM.
It feels that the rootElements approach solves this problem simpler than
the relationships approach unless I'm missing something.
William
On Thu, Jul 22, 2021 at 5:23 PM David Kemp <[email protected]> wrote:
> It does. It's certainly possible to loop over all the elements to build
> an index, but the conversation included identifying the SBOM element
> immediately upon loading the document. Finding the root element list in a
> known location near the beginning would satisfy the efficiency goal.
>
> Kate also mentioned grep-ing the whole document (which is as inefficient
> as building an index), but the advantage of that is that "DESCRIBES" is a
> hard-coded relationship type so it's obvious what to grep for. We'd need
> an equivalent list of well-known element type constants, which we'd have
> after defining the serializations, or we could say right now that the class
> names are those constants, and list them: "Snippet", "File", "Package" and
> "SBOM", plus whatever we come up with for identity elements.
>
> Dave
>
>
> On Thu, Jul 22, 2021 at 3:30 PM William Bartholomew <[email protected]>
> wrote:
>
>> I don't see SBOMs as any more "special" than any of the other element
>> types, if you wanted to know all of the SBOMs in a document you'd simply
>> loop through the elements looking for that element type, just like you
>> would if you were searching for packages or files.
>>
>> rootElement is intended to communicate that for this document (or
>> contextual-collection) these are the elements you should start with to
>> build a graph. If the intent of the document is to communicate an SBOM then
>> it would be natural for the rootElements to be SBOMs, if the intent of the
>> document is to communicate a set of identities then it would be natura for
>> them to be identities. They are simply a hint of where to start based on
>> the document author's intent of the document, if you're consuming the
>> document for a different intent then you can search the elements for
>> whatever you're looking for.
>>
>> Does that make sense?
>>
>> William
>>
>> On Thu, Jul 22, 2021 at 12:15 PM David Kemp <[email protected]> wrote:
>>
>>> I'm bothered by the same question that's bothering Kate.
>>>
>>> We discussed:
>>> 1) a collection of elements under a single namespace is a "Document"
>>> 2) the elements don't have to be related, they could be a bunch of
>>> identities
>>> 3) the document lists zero or more root elements
>>> 4) the document contains zero or more relationship elements (from_id :
>>> type : to_id)
>>> 5) properties have types, i.e. both structured "relations" and simple
>>> "attributes":
>>>
>>> *OWL object properties data properties*
>>> E-R relations attributes
>>> OOP range is class range is datatype
>>>
>>>
>>> Since we can no longer say that a Document is a single SBOM that
>>> describes some target of analysis, how do we signal that a Document
>>> contains zero, one, or more SBOMs? (Document is no longer a synonym for
>>> SBOM, it is now a synonym for "bundle of stuff that can be serialized".
>>>
>>> If we are going to deprecate the "id_x DESCRIBES id_y" relationship
>>> element, we're going to need a way of designating that a root element in a
>>> bundle is an SBOM. Without having concrete serializations to play with,
>>> it's not obvious that root element X traces down to Artifact ->
>>> ContextualCollection -> BOM -> (and finally arriving at) SBOM.
>>>
>>> I think we need a way of defining the "content type" of each root
>>> element without using relationship elements, but we haven't yet documented
>>> how to do it.
>>>
>>> Dave
>>>
>>>
>>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4113): https://lists.spdx.org/g/Spdx-tech/message/4113
Mute This Topic: https://lists.spdx.org/mt/84386487/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
