THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Technical Team/Minutes/2011-06-07"
From SPDX Wiki
< Technical Team | Minutes
(Convert to MediaWiki syntax) |
|||
Line 1: | Line 1: | ||
− | + | == Attendees == | |
− | + | ||
− | + | * Bill Schineller | |
− | + | * Kate Stewart | |
− | + | * Nicholas Loke | |
− | + | * Steve Crawford | |
− | + | * Peter Williams | |
− | + | * Gary O’Neall | |
− | + | ||
− | + | == Agenda == | |
− | + | ||
− | + | * Review current spec published 6/6/2011 | |
− | + | ||
− | + | == Review == | |
− | + | ||
− | + | * Language updated from the legal team | |
− | + | * Request review from Kirsten for the legal language | |
− | + | * Still some review comments in the Legal team, so there may be some additional changes | |
− | + | * Request for technical team to review and send Kate a document version under change revision mode to highlight any review comments or changes | |
− | + | * Request for a spreadsheet example including the URI for artifactOf – Gary | |
− | + | * Appendix II. RDF Data Model Implementation – needs a review to make sure it is in sync with the latest spec (especially naming) | |
− | + | * hasFile property on the document – hasFile is a property of package. Having a property at the document level is OK, but we would like to add such a property in the future. Concern about the name “hasFile” at the document level. Agreed to “referencesFile”. | |
− | + | * Discussion on having a property from the file to the document – agreed to postpone any changes until there is a use case which benefits from this relationship | |
− | + | * artifactOf – need for more information to describe how it is used. Produce some examples. | |
− | + | * Need to produce instructions on how to use the spec. | |
− | + | * PackageVerificationCode excluded file, need to review/update the cardinality – 0 or more – some question/concern on the language used to describe the cardinality (0 or more mandatory or optional) | |
− | + | * PackageVerificationCode excluded file – review syntax in the main document | |
− | + | * Conjunctinve/Disjunctive licenses – should the cardinality be 2 or more – tradeoff of additional effort for tooling to interpret manage degenerative case. Agree to 2 or more as the cardinality. | |
− | + | * SimpleLicenseInfo discussion – Should we have SimpleLicenseInfo a straight subclass of AnyLicenseInfo? Would be more constraining, but would also match the conceptual model – proposed for next week’s agenda | |
− | + | * Proposal for embedded octect stream – proposed for next week’s agenda | |
− | + | ||
− | + | [[Category:Technical|Minutes]] | |
+ | [[Category:Minutes]] |
Latest revision as of 13:12, 6 March 2013
Attendees
- Bill Schineller
- Kate Stewart
- Nicholas Loke
- Steve Crawford
- Peter Williams
- Gary O’Neall
Agenda
- Review current spec published 6/6/2011
Review
- Language updated from the legal team
- Request review from Kirsten for the legal language
- Still some review comments in the Legal team, so there may be some additional changes
- Request for technical team to review and send Kate a document version under change revision mode to highlight any review comments or changes
- Request for a spreadsheet example including the URI for artifactOf – Gary
- Appendix II. RDF Data Model Implementation – needs a review to make sure it is in sync with the latest spec (especially naming)
- hasFile property on the document – hasFile is a property of package. Having a property at the document level is OK, but we would like to add such a property in the future. Concern about the name “hasFile” at the document level. Agreed to “referencesFile”.
- Discussion on having a property from the file to the document – agreed to postpone any changes until there is a use case which benefits from this relationship
- artifactOf – need for more information to describe how it is used. Produce some examples.
- Need to produce instructions on how to use the spec.
- PackageVerificationCode excluded file, need to review/update the cardinality – 0 or more – some question/concern on the language used to describe the cardinality (0 or more mandatory or optional)
- PackageVerificationCode excluded file – review syntax in the main document
- Conjunctinve/Disjunctive licenses – should the cardinality be 2 or more – tradeoff of additional effort for tooling to interpret manage degenerative case. Agree to 2 or more as the cardinality.
- SimpleLicenseInfo discussion – Should we have SimpleLicenseInfo a straight subclass of AnyLicenseInfo? Would be more constraining, but would also match the conceptual model – proposed for next week’s agenda
- Proposal for embedded octect stream – proposed for next week’s agenda