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

Technical Team/Minutes/2014-09-16

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 21:51, 16 September 2014 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

September 16, 2014

Attendees

  • Gary O'Neall
  • Bill Schineller
  • Scott Sterling
  • Jack Manbeck
  • Mark Gisi
  • Jack Manbeck
  • Kirsten Newcomer

Agenda

  • Case sensitive license expression
  • Review Kate's draft document

Case sensitivity for license information

  • Agree that operators should be case insensitive
  • License ID's are case sensitive
  • Mark will verify with legal team before concluding

Review of Kate's Draft Document

  • reviewing document located at: https://docs.google.com/document/d/10dJ3Hjc29oAlU56OEojq4HM8jMLK6IYYGR7JJyEKubQ/edit
  • Note - some changes were made in suggestion mode and some were made in edit mode. As we got into the call we decided to use suggestion
  • File Type
    • Change definition of file type to match our discussions
      • Add intrinsic to the file type - not sure how to word to make it readible. Added "independent on how the file is being used" - docs is updated
      • Agreed to remove the sentence on license impact - it is an interpretation which may not be accurate
    • Text file type - changed the restriction that source should be used since we can now have multiple file types (e.g. have both Text and Source file types).
    • Discussion on examples - generally agree that more examples are better
    • Moved README example for text down to the example section
    • SPDX definition should be more specific - an SPDX file, not just a file containing SPDX information
    • Tweaked wording for documentation to make it less of a relationship and more intrinsic to the file
    • Added application type example
  • Relationship types
    • Nameing of relationship types
      • Needs to be unique in RDF - porposal RelationshipType_XXX -
      • Do we need to be consistent in tag/value?
        • Less readable but more consistent
        • If not unique, may make the parsing tools more difficult
      • Table the discussion on the prefixes for tag/value until we pull Kate back in
    • SPDXElement description - move what an element is to the examples
    • Comment cardinality - changed to optional one - should make it a best practice for adding comments if the type is other
    • Added 8.3 - related SPDX document checksum - preliminary wording
    • Agreed that it is OK to go with the blue pattern
    • Change generated from example to a source file / binary file relationship