Greetings all,
In preparation for Tuesday's call, I wanted to update everyone on the progress we made at the recent Open Source Summit and the current state of Issue #55: Support multiple SPDX file format like project HayStack <https://github.com/spdx/spdx-spec/issues/55> . By the end of the conference, I think we came up with an approach that could work without too much effort once we resolve a couple of issues. For our call on Tuesday, I would propose we discuss the two remaining issues for supporting the multiple file formats as well as identify any new issues we didn't consider at the conference: * Specify related SPDX element is an ID: https://github.com/spdx/spdx-spec/issues/96 * Camel Case for different formats: https://github.com/spdx/spdx-spec/issues/95 Below are some details on the discussions at the conference. We made a lot of progress in the discussion with James in comparing the XSD to the generated XML and identified 2 issues: * Difference in CamelCase for the properties * Difficulty in referring to the other SPDX elements in the relationship object which tend to create circular graphs We also discussed generating the Java classes and comparing the code as a next step (see below for an update). Thomas and I had a very productive discussion and we realized that the issue with the relationship object was present in the YAML and JSON formats as well. We came up with a solution where the definition of the relatedSpdxElement would be the ID of the SPDX element it is related to. The ID could be internal to the document or an external document ref. This is similar to how the current spec handles references to the snippetFromFile in the tag/value format (see section 5.2 in the spec). When Thomas and I discussed this, we were thinking of changing this definition for all formats including RDF. Since our discussion, I am now thinking we should leave the RDF as is and continue to refer to the related SPDX elements as URI's rather than ID's. This occurred to me as we were demoing the use of RDF/SPARQL to reason information from an SPDX document. I realized that if we changed the spec, a lot of the queries against the RDF would no longer work since there wasn't a direct relationship between the elements. Not changing the spec would also allow us to maintain backwards compatibility - we could still make it a 2.2 rather than a 3.0 release item. After the conference, I generated the Java classes based on the XSD James produced. We need to do a bit of work to map the class names correctly (see https://github.com/mil-oss/spdx-xsd/issues/3) and resolve the camel case issue (see below). I went ahead and submitted the following issues against the spec: * Specify related SPDX element is an ID: https://github.com/spdx/spdx-spec/issues/96 * Camel Case for different formats: https://github.com/spdx/spdx-spec/issues/95 For the SPDX tools, generating the new formats will be pretty straight forward. Consuming them would be more work - this may be the critical path for releasing the spec and additional contributions / help are more than welcome. For 3.0, it would be great to re-write the tools to use classes generated from the XSD. This would reduce the possibility of bugs and greatly simply the Java code. I'm tempted to do this for 2.2, but it would be a pretty ambitious amount of code and cause some compatibility issues for people using the library directly. Regards, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: <mailto:[email protected]> [email protected] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3616): https://lists.spdx.org/g/Spdx-tech/message/3616 Mute This Topic: https://lists.spdx.org/mt/26152780/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
