Hi Gang,
I pasted the document contents along with my responses below. The use case I am thinking about is where you have an application SPDX document and one or more library SPDX documents you would like to merge into a new SPDX document for the complete (as in application + libraries) distribution. In this use case, the application SPDX document could be used as a "master" to take some of the package level information. Kotrappa - feel free to suggest different approaches if my responses do not work for your use case. All - if you could take a couple minutes to review the questions and responses below and let us know if you have any alternative approaches/ideas. Thanks, Gary The purpose of this document is to define the solutions of merging SPDX Document. I see the SPDX Document in tag format view. 1. In the SPDX document head, there are three rubrics: SPDXVersion, DataLicense, and DocuemtComment. So, if the version and datalicense’s values are the same, we will be fine. What if these values are different? Is there possible these values to be different from the documents that we are going to merge? About the DocumentComment, do we get new input comment from the user? [Gary] Suggest we generate a new output SPDX document with the latest version and the specified DataLicense for that version. As long as the parser supports the version, the input versions can be different. The DataLicense for the input should match the spec. We could verify this and produce a warning if it is not correct (BTW - if you call the verify method in the SPDXDocument class, it will verify the appropriate data license). For the document comment, I am thinking that it is either left blank or is an input parameter. 2. In the Creation Information section, the document has Creator, Created, and CreatorComment. Consider the user is going to create a new SPDX document, do we need to get new inputs from user? The user will be creator person value, whatever the user works to will be the organization value, and the SPDX Merge Tool will be the creator tool. Then, the program will get current date and time value from system. And, we need user to input new creatorcomment value. Or, we just run the merge process without any inputs. In this case, what we choose if the creation information is different. Mr. O’Neall said we may need to choose one of input SPDX document as master document and the others will be child documents. Therefore, the first input SPDX document will be the master document. We can add child documents’ creator information into the master document’s creatorcomment. [Gary] I like the first option of having user inputs for the user to add an organization or person creator, but we could just use the Tool:SPDX Merge Tool. If we don't take any input, we could generate a creator comment stating that the SPDX document was created from the merged SPDX files (e.g. "This SPDX document was created by merging [master SPDX document package name:version] with [library spdx package name1], [library spdx package name2]..."). 3. In the Review Information section, if we consider the merged document as a new SPDX document, how we put value in the review section? Or, if we choose a master SPDX document, what about the review information from the child document? If there is no up boundary record number, we can merge review information all together. [Gary] I would just leave this blank since it is a new document. 4. In the Package Information section, if we choose one input document as master document, then we use information from it as the new document package information. However, I think the package version, package verification code, package description, package license declared and package license concluded, these value need to be modified. Maybe other values also need to be changed. For example, the package file name is changed after the document merged because of new file information added. In the package license declared and package license conclude, the license information will be changed according to the result from license merging process. I will describe it bellow. [Gary] Very good point. For certain, the packageVerificationCode will need to be recalculated. Fortunately, all of the data needed to recalculate this is present in the input SPDX files. From a usage perspective, I wonder if it would be OK to create a master SPDX file which contains all the correct values for the output merged document with the exception of the verificationCode. The DeclaredLicense (and possibly the ConcludedLicense) would be taken from the master, but the LicenseINformationInFiles would be calculated. 5. In the File Information, if we have two files, they have same file name and file checksum, but the license concluded and license information in file are different. Do we count them as separated file information, or I need to merge them together by merging the information in license concluded and license information? [Gary] I'll need to think about this a bit more, but I am leaning to leaving these as separate files. Changing the declared license for a file seems like a risky approach. Below is the merge processes I design to do and assume we choose one input document as master document: · The first input SPDX document will be the master document · The merge processes is from bottom to top: License Information -> File Information -> Package Information · Read all license information from master document and store values in the ArrayList< SPDXLicenseInfo > MasterLicInfo · Bring in child documents license information one by one per document and compare with the master license information. The comparison uses the value from license extracted text which I believe I get use rdf parser to get it. If the value is the same, no new value add to MasterLicInfo. At the same time, a method will read license concluded and license info in file values from file information in this particular document. And assign the new values by use the license ID from master document. If the license extracted test value is not the same, then the new value will add to the ArrayList. Again, a method will read license concluded and license info in file values from file information in this particular document. And assign the new values by use the position integer from ArrayList. Repeat the processes until all child documents’ license information has been read and compared. I will discuss with Mr. O’Neall about code details here. · During the file information merging, so far I use HashSet to remove the duplicated file information elements from all input documents. The further merge step will depend on how we define the solution from above question in the file information section. · In the package information merge, if the package license declared information based on the package license concluded value. Then the new license ref ID can add to the license declared from license concluded. [Gary] The license mapping will be a bit tricky. You will need to maintain a mapping between the license ID's used in the resultant document and the license ID's used in the input SPDX documents. Rather than reading and storing the values from the master in an ArrayList, I would create deep copies in the new resultant SPDX document and store the resultant values and create a translation table at the same time. We can discuss in more detail on a call later this week. From: [email protected] [mailto:[email protected]] On Behalf Of Gang Ling Sent: Friday, June 27, 2014 11:43 AM To: [email protected] Subject: Gang Ling - Questions on Merge Process Hello everyone I attached a document about a list of questions of the document merge processes. Please add comments on the document and send it back. So I can continue moving on the program coding. Thanks, Gang -- Gang Ling University of Nebraska at Omaha College of Information Science and Technology LinkedIn Profile <http://www.linkedin.com/in/gangling/>
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
