Open meretp opened 1 year ago
Thanks @meretp for the detailed explanation of the issues.
In general I would expect that the comparison is somehow independant from the direction of the relationship although I see that this is a rather complex topic and I can understand that the comparison would only be about the "actual present" relationships.
This would involve an assumption of equivalence for different relationship types and directions. I think this is a reasonable assumption, but it would be good to document those in the spec itself.
You're right in that this would be a rather complex fix, but I think it is doable.
Another problem, which is related to this, is the following: For json, yaml and xml there are additionally the tags "documentDescribes" and "hasFiles" in packages to represent DESCRIBES, resp. CONTAINS-relationships. The tools-python avoid duplications when serialising and do not write for example SPDXRef-DOCUMENT DESCRIBES SPDXRef-File additionally out, because this information is already mapped in "documentDescribes: [SPDXRef-File]". This leads then with the comparison however again to the fact that two documents are not evaluated as equal.
The Java deserializer code for JSON, YAML and XML should handle deserializing these properties into a normalized form. So, a document which has a describes
property should translate to a DESCRIBES
relationship. Perhaps there is an issue with the deserialization?
Do you think it would make sense to add some additional logic to the comparison that checks for this kind of semantic equivalence of the relationships ( so including the information from hasFilesand documentDescribes) and not only for actual existence?
Yes - but it would be a bit of work.
In looking at the effort involved, I don't think it would make sense to fix this before 3.0.
The 3.0 spec has some structural changes in the relationships that will make this a different solution and perhaps easier.
@meretp - let me know if you agree
@goneall I agree with you. Considering the effort involved and the rather rare use case, I wouldn't fix it now either.
Clarification on the "won't fix" label - won't be fixed before SPDX spec version 3.0. Once the SPDX spec version 3.0 is released, we'll reconsider working on this issue.
I had a look into the comparison method in the tools-java to find out if we can also use them in the testbed. As this method originates from this repo, I decided to open the issue here. So, apart from the fact that we would need to change one namespace to compare two equal docs, I ran into another issue. This is also an issue within the testbed (#51). When comparing the doument
with
the resulting xlsx file lists a difference in the file relationships (which is understandable as the relationship
Relationship: SPDXRef-fileB DESCRIBED_BY SPDXRef-DOCUMENT
is missing -although it is a duplicate ofSPDXRef-DOCUMENT DESCRIBES SPDXRef-fileB
). But the result also marks document describes with diff although the values in the rows below are the same. The same holds for the file relationships of./fileA.c
. Why is this marked as diff? In general I would expect that the comparison is somehow independant from the direction of the relationship although I see that this is a rather complex topic and I can understand that the comparison would only be about the "actual present" relationships.Another problem, which is related to this, is the following: For json, yaml and xml there are additionally the tags "documentDescribes" and "hasFiles" in packages to represent
DESCRIBES
, resp.CONTAINS
-relationships. Thetools-python
avoid duplications when serialising and do not write for exampleSPDXRef-DOCUMENT DESCRIBES SPDXRef-File
additionally out, because this information is already mapped in "documentDescribes: [SPDXRef-File]". This leads then with the comparison however again to the fact that two documents are not evaluated as equal.Do you think it would make sense to add some additional logic to the comparison that checks for this kind of semantic equivalence of the relationships ( so including the information from
hasFiles
anddocumentDescribes
) and not only for actual existence?