THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Minutes/2015-09-29

From SPDX Wiki
Jump to: navigation, search

Sept 29, 2015

Attendees

  • Gary O'Neall
  • Yev Bronshteyn
  • Bill Schineller

External Identifiers

  • Reviewing document at https://docs.google.com/document/d/1j6LWnkh5GbMV9Xo5_zJ0wTNLROEIa4o1OU279YueI90
  • Significant changes since last time based on feedback:
    • optional 3rd part of identifier ‘External Repository Location’ (fulfill need to say ‘which debian distro archive’ or which Maven repository (if not default Maven Central)
    • External Identifier relaxed wording to allow ‘whichever level of specificity (e.g. package, version, architecture…) the external system supports and the SPDX Document creator provides.’
    • Appendix list of Package Managers / Code Repositories edited to exclude general build tools (gradle), and to be inclusive of forges such as github, sourceforge, codeplex, googlecode
  • Updates made realtime to the document during meeting
  • Section 3.20.4
    • Reviewed text - generally agreed with proposal
    • External Repository Location - Agreed that this is not always going to be a URL - should be more general (e.g. for Debian ‘deb http://httpredir.debian.org/debian jessie main’ expresses which distro / set of packages)
  • Section 3.20.6
    • Should the externalSystemIDType be an individual or a string?
    • Individuals need to be defined ahead of time, would constrain ongoing development
    • Leaning towards string, but leaving this open
  • Delimiter for tag/value selection
    •  :: is used in Perl (REJECT THIS?)
    • Propose ### (REJECT THIS?)
      • Used as comments in tag/value
    • Propose single quote to enclose location (REJECT THIS)
    • We could use the same approach as ArtifactOf where there are multiple tags
    • Proposed solution A - consistent with ArtifactOf
      • 3 separate tags "PackageExternalIdentifierType", "PackageExternalIdentfierID", "PackageExternalIdentifierLocation".
      • Use optional <text> if any of the special characters or multiple lines is used
    • Proposed solution B - Consistent with Checksum
      • Use a colon to separate the fields
      • Optionally wrap the individual fields with <text></text> if multi-line or uses any special characters (e.g. debian:<text>libmtp-common/1.1.9-2/all</text>:<text>deb http://httpredir.debian.org/debian jessie main</text>)
  • Reviewed tables in the Appendix
    • BNF grammar may be too high a bar - suggest having a link to an external description which may (or may not) have a BNF grammar
      • Changed last column to reference the external definition of the ID
  • Question - Is the <text> optional for those fields that use it? Not clear from the spec - seems to indicate optional in the description, but there are one line examples where <text> is used - should clarify spec
  • Bug in spec - section 5.1.6 - RDF term and example for LicenseID/LicenseId is inconsistent - should be LicenseId to be consistent with Ontology.