Potential punch list for issues regarding the SPDX2->3 conversion

[armintaenzertng]

This is a punchlist of problems we are currently facing when converting SPDX2 to SPDX3. See also this spreadsheet for an overview of the current state.
Please feel free to comment on any of the points below. Small remarks can go right here in this issue, but if you want to start an in-depth discussion on any of the points, please open and link a new issue (edit this post) to keep this issue comprehensive.

CreationInformation properties:

• SPDX 2->3 conversion of DocumentNamespace #87

File properties:

• SPDX 2->3 conversion of FileTypes #82

Package properties:

• SPDX 2->3 conversion of PackageFileName #83
• SPDX 2->3 conversion of filesAnalyzed #84
• SPDX 2->3 conversion of excludedFiles in PackageVerificationCode #85
• SPDX 2->3 conversion of Package SourceInfo #86
• SPDX 2->3 conversion of ExternalPackageReferences #81

Relationship properties:

• relatedSpdxElement
  • This gets converted to a (mandatory) to property of the SPDX3 relationship, which is an Element. But relatedSpdxElement can also take the values NONE and NOASSERTION. How should these be converted to an Element?
  • This is covered by the completeness relation

Snippet properties:

• SnippetFromFile
  • Should this be converted to a contains relationship from the containing file to the contained snippet?
  • Gary remembers that it was decided to have it as a relationship.

[goneall]

My 2 cents on the punchlist - since I won't be able to join next Tuesday's tech call:

DocumentNamespace - Is it correct that this converts to NamespaceMap(prefix=SPDX2-DocumentSpdxId, namespace=SPDX2-DocumentNamespace)?

I don't think so. I recall a discussion where we could represent a "default namespace" that would be used. That being said, I don't see a way to represent the default namespace using the namespace map. Perhaps others on the call recall how this is done.

FileType - Will probably be converted to SoftwarePurpose, but the FileType values BINARY, SPDX, AUDIO, IMAGE, TEXT and VIDEO don't have an analogue (yet?). The last four types could maybe be mapped to data?

From the 2.3 spec: "File Type is intrinsic to the file, independent of how the file is being used." whereas SoftwarePurpose is more about the intent of how the file is used. So, FileType should be translated to contentType which uses the MIME standard.

Will there be need for setting the contentType from this? Contrary to contentType, FileType is not restricted to a single value, thus different FileTypes might call for different contentTypes, which would be problematic.

Good point - I think we should change the cardinality in the spec to allow for more than one content type.

packageFileName - Will this be a Relationship to a file? packageFileName may also point to a folder, though.

We were thinking of using a relationship. If it is a folder, then we would probably create a separate "package" definition to represent the folder? The folder scenario is one I have not thought through and probably deserves more discussion.

If a future integrity profile requires a checksum, it may not be possible to translate to a file relationship since the checksum is optional in SPDX2.

If that is the case, we can require the checksum in the Integrity profile

filesAnalyzed - There is no integrity profile to take the place of requiring checksums for files. Some uses of filesAnalyzed indicate that a certain level of tooling was applied to the source. We would lose this information if this field is removed.

I wonder if the build profile would service this purpose?

PackageVerificationCode - In SPDX2 we could express a list of excluded files, how is this possible in SPDX3?

The idea is we would have a separate verification implementation for packages that would include this information. The work for this hasn't been done.

SnippetFromFile - Should this be converted to a contains relationship from the containing file to the contained snippet?

I think that was the discussion, however, I still think a property would be easier to parse/follow. If I recall, I reluctantly agreed to it being a relationship.

[lumjjb]

filesAnalyzed - There is no integrity profile to take the place of requiring checksums for files. Some uses of filesAnalyzed indicate that a certain level of tooling was applied to the source. We would lose this information if this field is removed.
I wonder if the build profile would service this purpose?

The build profile has some established relationships on the files themselves. So the information would be encodable by the build profile relationships. However, that is just the ability to express the relationship. I'd be curious to discuss what the integrity story would look like (as it ties into verification). I think that's probably something to discuss... since with the build profile the granularity of identities may be more granular and harder to manage.

[kestewart]

This is resolved by addition of Changes Annex to the 3.0 Specification (was migration guide) from Gary. Marking this as resolved.

[rnjudge]

@kestewart @goneall is this covered by https://github.com/spdx/spdx-spec/blob/development/v3.0/docs/annexes/diffs-from-previous-editions.md?

[goneall]

Since the only remaining item issue #84 is now targeted for 3.1 and all other items are documented in the diff's annex, I'm going to close this issue