Is this valid SPDX?

[vargenau]

blackduck.spdx.txt

The attached file is adapted from SPDX in tag:value format generated by BlackDuck.

The Python tools tells that this is invalid SPDX.

pyspdxtools -i blackduck.spdx
ERROR:root:There have been issues while parsing the provided document:
Element Package is not the current element in scope, probably the expected tag to start the element (PackageName) is missing. Line: 26

I tend to agree with that, as the FilesAnalyzed clause does not follow the package.

But the Java tools say that the file is valid SPDX.

And the BlackDuck people claim that they cannot find something in the standard explaining why this is illegal.

So who is right?

[vargenau]

See also spdx/tools-python#856

[goneall]

I've noticed that different tools treat relationships differently. The Java tools treats relationships as a property for the package or file whereas other tools (which I believe includes Python) treats the relationship as a separate object. This may explain the different behaviours in validation. All properties for a given object needs to be grouped together for valid tag/value processing (otherwise we wouldn't know which properties go with which class).

My suggestion would be to add relationships after all other properties to be compatible with the Python (and other) parsers even though technically the SPDX 2.X model diagram shows relationships being a property.

I don't think we want to change the behavior of the Java tools since it more closely follows the SPDX 2.X model.

Note that in SPDX 3.X we changed both Annotations and Relationships to be independent objects which is consistent with the Python implementation.

[vargenau]

Hi @goneall
Thank you for your answer.
In the example file I gave, it seems clear that it would be better to put the

FilesAnalyzed: false

before the relationships.

But my main question was "Is the code really invalid or not?" (and if so where to find the explanation in the standard).

From your explanations, I understand it is valid.

The practical issue we have is that we validate the code with the Python tools before importing to our internal tool, and we do not import if invalid.

So we cannot import the BlackDuck code.

And it will be difficult to convince BlackDuck to modify their output if it is not invalid.

I will see if the Python validator can be updated.

[armintaenzertng]

From the specification about the document structure:

an SPDX document [...] is made up of a set of one or more sections, instances of which contain information in the form of fields.

The sections are then defined. Note that packages and relationships form distinct sections.

Annotations and relationships for the package may appear after the package information before any file information.

(Emphasis by me.) This would not make sense to me if relationships could also appear within the package information.

So yes, I would maintain that the the provided SPDX is invalid.

[vargenau]

Hi @armintaenzertng
Thank you very much from your answer.
From the reference your provide, the BlackDuck SPDX is indeed invalid.
I will communicate the reference to them.

@goneall
Do you agree with Armin's answer?
Would it be easy to modify the Java parser so that it issues a validation error?

[goneall]

Do you agree with Armin's answer?

Yes - that makes sense

Would it be easy to modify the Java parser so that it issues a validation error?

Not a difficult fix, but not trivial either. I probably won't fix it in the near term - a few higher priority SPDX activities at the moment. Hopefully pointers to the spec and this discussion will be enough to encourage BD to change their implementation.

[vargenau]

Thank you @goneall

It's not urgent to fix this.
I have transmitted the info to Black Duck.
I was asking as Black Duck is telling me the code is valid as they use the online validator.