spdx · goneall · Sep 6, 2022 · Sep 6, 2022 · Oct 14, 2022
diff --git a/tech/2022-09-06.md b/tech/2022-09-06.md
@@ -0,0 +1,95 @@
+# SPDX Tech Team meeting - 6 September, 2022
+
+## Attendees
+
+* Alexios Zavras
+* Bob Martin
+* David Edelsohn
+* David Kemp
+* Gary O'Neall
+* Henk Birkholz
+* Jennie Kaufmann
+* Joshua Watt
+* Karsten Klein
+* Kate Stewart
+* Maximilian Huber
+* Michael Herzog
+* Nicolaus Weidner
+* Sebastian Crane
+* Thomas Steenbergen
+
+
+## Agenda
+
+* Finding when meetings are?
+* Review last week's punch list
+* Strategies for Serializations 
+* Remaining classes we didn't discuss on last week's call:
+  * Actor
+  * Identity
+    * Person
+    * Organization
+    * Tool
+  * Collection
+  * Bundle
+    * SpdxDocument
+    * BOM
+    * SBOM
+
+## Notes
+
+* Ways to find when meetings are: 
+    * https://github.com/spdx/meetings
+    * https://spdx.dev/participate/tech/
+    * https://lists.spdx.org/calendar
+
+* Issue under the model - #29 https://github.com/spdx/spdx-3-model/issues/29
+  * AI: Sebastian to write up Data proposal. 
+  * Package Download location - move it back to be optional.  Ambiguous what if multiple download locations.   From an auditor perspective it matters where the SPDX producer got it from.   
+  * Resolved:   Package Download location 0..1 cardinality.   Note:  If you want to have multiple, create separate element and set relationship to COPY_OF. 
+  * Artifact URI is an identity.   Should be a URI as it may not tell you where it is.  Discussion if Package URL should be promoted to Artifact, and we wanted William's input.
+  * Should Artifact URI be moved back to Artifact class vs. external reference?   We want a URI that is a single identity of something.   We need to characterize whether we have an identity.   David thinks that Artifact URI should be a property.   
+  * Resolved (as long as William & Sean doesn't disagree):  Artifact URI is a property of Artifact class with cardinality of 1..1
+     * the PURL may need to be constrained to be unambiguous.
+     * If you define the artifact URI properly, you can always make it unambiguous. 
+     * Some concern that ok for Package, File, but some concern about Snippet.  (ie. add syntax byte range)
+  * Should location be added to Artifact Class?
+  * Elements - should External Identifiers been better defined?
+  * Conclusion:  Need a session discussing location & identifiers. William, Sean & Gary need to particiapte.
+  * Gain concensus on type of extension type?  Need Sean.   Information/data model.
+  * Dealing with Extensions 
+      * Group concensus let there be an "extension" profile (where all the hooks are).   Authoring tools all supprt, but consuming may ignore at their discretions. 
+      * Proposal: Extensions field will be encapsulated in Profile and removed from Core Model type. 
+      * Reminder:  Spec is the superset,  and profiles say which sets you're going to support. 
+      * What's the formulation for existing profiles?  (need to pick up when start drafting)
+      * How do we treat extension - is it a separate profile or not?
+      * Profiles are specified in separate section?
+  * Clarify if VerifiedUsing should be integrity of thing?  or whole scope? 
+     * Conclusion: VerifiedUsing should be integrity of thing outside SPDX  (ie. could include hash and signature).  (Note:  Circle back with Sean & William about what happens in SPDX & results of canonicalization work)
+     * Sebastian raised should it be Hash - but is ok to go along.    Some concern about all the information in element at this point time. 
+     * Henk what about external references you want to verify?  May want to be in element. 
+     * Canonicalization is coming up with algorithm to verify inside SDPX.
+     *  annotation types are REVIEW and OTHER, nothing else for the core
+     * Enumerations: should we just allow "OTHER"?  for all enumerations? 
+        * Should profiles enable adding fields to enumerations?   Private extensions?  Serialization implications.
+        * Should they be closed or open for all SPDX.   Possibly wrap into same discussion as extensions.   Open.
+        * Number index to all the data to facilitate enumerations.
+    * Conclusion:  An actor may or may not be tied to an identity.    
+        * With an optional set of identifiers.    You can provide as much or as little information as appropriate.   If you know additional information about the actor, you can add it, but not requiring. 
+    *  Relationships:  see issue #5. https://github.com/spdx/spdx-3-model/issues/5  Please read through it and add any queries there, then we will bring back.   Note: there is an issue in the SPDX specification repository. 
+    * Profiles - see listed issues as required reading before extensions in profile. 
+
+* Strategies for Serializations
+   * Different communities use different serialization formats.  
+   * Implementers group is recommending that JSON be the primary serialization format.
+   * We need to articulate the "Why" and then conciously add / delete specific ones. 
+   * Gary: Objective: increasing adoption, support multiple formats.   Believe we want to continue to do this. 
+   * Sebastian: How to refine do which ones are useful.  example:  XML features.
+   * Gary suggests splitting into 3 questions:   All 2.X or depricate some?   Add any serialization format?   Have a primary for 3.X?    
+      * Primary for 3.X had JSON LD from primary discussions.
+      * Alexios:  "Supporting" we need to clarify - spec supports or tooling supports? 
+      * Joshua:  Can only pull in Stock JSON (Python support due to tooling constraints. ).   Only going to manipulate JSON.    XML and JSON good for Yocto.
+      * David:  Define what trying to exchange, as an abstract syntax tree, and then transform to any serializaitons.   Have to communicate same information.   Syntax of document that can be translated to any data format. 
+      * Thomas: Serialization should be done first, have legacy decisions to consider.   ORT does JSON, YAML & XML.   Just want to use standard converter that JSON <-> YAML <-> XML. 
+
+* No meeting next week, unless William sends out email saying it's on. 
diff --git a/tech/decisions.md b/tech/decisions.md
@@ -17,6 +17,10 @@
 | details of a subject can go into a profile | 15-Apr-2022 | details in core | [SPDX 3.0 Model Session - April 15, 2022](https://github.com/spdx/meetings/blob/main/tech/2022-04-15-model-session.md)
 | SpecVersion property will be a string that is constrained to one of a set of canonical options published by SPDX in the current or any future specifications | 17-May-2022 | Structured property, subset of SemVer in spec | [Tech Team Minutes 17 May 2022](https://github.com/spdx/meetings/blob/main/tech/2022-05-17.md)
 | SPDX-Snippet-Begin and SPDX-Snippet-End used to mark snippets in source files | 6-Jun-2022 | SPDX-Snippet-Begin: ID/Name ... | Tech Team Minutes 7 Jun 2022
+| Package Download location cardinality 0..1 | 6 Sept 2022 | cardinality 0..*, Note: If you want to have multiple, create separate element and set relationship to COPY_OF. | Tech Team Minutes 6 Sept 2022 |
+| VerifiedUsing should be integrity of thing outside SPDX | 6 Sept 2022 | VerifiedUsing also used for SPDX metadata | Tech Team Minutes 6 Sept 2022 |
+| annotation types are REVIEW and OTHER, nothing else for the core | 6 Sept 2022 | Based on prior decisions | Tech Team Minutes 6 Sept 2022 |
+| An actor may or may not be tied to an identity | 6 Sept 2022 | Based on prior decisions | Tech Team Minutes 6 Sept 2022 |
 | Remove version from profile property | 4-Oct-2022 | Each profile has a version property | [Tech Team Minutes 4 Oct 2022](https://github.com/spdx/meetings/blob/main/tech/2022-10-04.md)
 | Profiles are released in sync with spec releases | 4-Oct-2022 | Profiles may be released independently | [Tech Team Minutes 4 Oct 2022](https://github.com/spdx/meetings/blob/main/tech/2022-10-04.md)
 | Add NONE to SoftwareDependencyRelationship | 4-Oct-2022 | Keep as is | [Tech Team Minutes 4 Oct 2022](https://github.com/spdx/meetings/blob/main/tech/2022-10-04.md)