Hi Nuno,
Thanks for the suggestion on the line numbers. Agree it would be much easier to read/parse. We did discuss this some time ago, and there were some concerns regarding the definition of a line. I recall 2 issues being raised: 1. The definition of a "line" varies a bit, we will need to be very specific how we count them (e.g. LF, CR/LF, etc.) and include that into the spec with specific Unicode values (lessons learned from defining the Verification Code algorithm). 2. Many JavaScript files have the lines removed. The only way I can think of specifying the snippets for these files is to provide a byte range. #2 above is my biggest concern. can think of a few options where we could include line numbers: A. Require the byte range and have an optional line number range B. Have a required line number range but have a syntax for optionally including the byte offset within the line (e.g. 24.152 would mean line 24 byte offset 152 within the line). C. Require line numbers and have an optional byte range D. Require either byte range or line number range (must be one or the other) Based on all of 30 minutes of thought, I am leaning toward B above since it is readable but still supports the JavaScript use case. I'm also OK with just using byte ranges, but Nuno makes a good point on the readability - it would be much easier to spot the snippet in a text editor if we had line numbers. Gary From: [email protected] [mailto:[email protected]] On Behalf Of Nuno Brito Sent: Wednesday, June 3, 2015 6:15 AM To: [email protected] Subject: Re: Snippets Proposal Hello, Happy to see snippet support being introduced. Would kindly request the possibility of using line numbers in addition of byte ranges because humans are unable of converting byte values into meaningful line positions without third-party tools. By comparison, plain text editors identify line numbers trivially. Don't know if helps, but on our reports with tag/value format we define code snippets using the following structure: FileName: ./dbmail-3.1.17/test-scripts/testpop.py FileType: SOURCE FileChecksum: SHA1: 14efb2a76ba62090270c6994976be67cc467b0e8 LicenseInfoInFile: GPL-2.0+ FileCopyrightText: <text>Copyright (C) 2004 Paul J Stevens paul at nfg dot nl</text> FileMatchSnippet: 64..73->187..194 85% github:ernesto27-userlogin-python-3c4962a/app.py The last tag refers to a snippet matching a third-party code snippet. No inference made about provenance nor applicable license, just a reference to similar code on the Internet. Looking forward to an official description format for snippets. With kind regards, Nuno Brito Message: 1 Date: Tue, 2 Jun 2015 06:39:51 -0700 From: "Gary O'Neall" <[email protected]> To: <[email protected]> Subject: Snippets Proposal Message-ID: <01f801d09d39$9b5f11a0$d21d34e0$@com> Content-Type: text/plain; charset="us-ascii" Here is a link to the RDF class for Snippet created during SPDX 2.0: http://spdx.org/rdf/ontology/spdx-2-0-rev-12/classes/Snippet___2057595658.ht ml I thought that this would be a good starting point. In terms of translating this to tag/value, here's a rough proposal: - Add a new section for snippets - Include the tags consistent with Snippet being a subclass of SpdxItem (annotation, relationship, name, comment, licenseConcluded, licenseInfoFromFiles, copyrightText, licenseComments). - Add a tag fromFile which would have a value of a SPDX Element ID (this could also be a reference external to the SPDX document). - Add a tag byteRange which would indicate the byte range in the file for the snippet Proposed definition of fromFile: File containing the SPDX element (e.g. the file contaning a snippet). Proposed definition of byteRange: String of the form \d+:\d+ denoting a range of bytes. For your reference, here is a link the snippets use case: http://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Consuming_code_snippe ts Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: <mailto:[email protected]> [email protected] -- http://triplecheck.net phone: +49 615 146 03187
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
