Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deserializing document does not populate documentNamespace in model store #26

Closed
nicoweidner opened this issue Sep 23, 2022 · 2 comments

Comments

@nicoweidner
Copy link

nicoweidner commented Sep 23, 2022

I used the following minimal example for testing:

SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
DocumentNamespace: some_namespace
DocumentName: SPDX-tool-test
SPDXID: SPDXRef-DOCUMENT

## Creation Information
Creator: Tool: test-tool
Created: 2022-01-01T00:00:00Z
## Relationships
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-somefile

FileName: ./foo.txt
SPDXID: SPDXRef-somefile
FileChecksum: SHA1: d6a770ba38583ed4bb4525bd96e50461655d2758
LicenseConcluded: LGPL-3.0-only
FileCopyrightText: <text>Copyright 2022 some guy</text>

I deserialized via:

var document = SpdxToolsHelper.deserializeDocument(file);

(where the tools helper is from tools-java, but it boils down to the tagvalue store from this repo).

While document.getDocumentUri() correctly returns the namespace, no value is present in the model store for documentNamespace, as can be checked via

document.getModelStore().getPropertyValueNames("some_namespace", "SPDXRef-DOCUMENT")

or

document.getModelStore().getValue("some_namespace", "SPDXRef-DOCUMENT", "documentNamespace")

Note: The problem seems specific to this store, at least the xml store does not have the same issue. I didn't try the other stores yet

@nicoweidner
Copy link
Author

nicoweidner commented Oct 5, 2022

@goneall This can be closed.

The issue came up while testing a new comparison tool (one version had the documentNamespace property, while the other didn't). However, the issue was rather that the jackson store should not save documentNamespace as a property (it's contained in the key anyway). So the tag/value store actually behaves correctly by not persisting documentNamespace.

See the linked issue for the corresponding discussion.

@goneall
Copy link
Member

goneall commented Oct 5, 2022

@nicoweidner Makes sense - closing this issue.

@goneall goneall closed this as completed Oct 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants