Skip to content

Latest commit

 

History

History
131 lines (124 loc) · 9.24 KB

2023-04-11.md

File metadata and controls

131 lines (124 loc) · 9.24 KB
Raw

SPDX Technical Team Meeting 2023-04-11

Attendees

  • Adolfo Garcia Veytia
  • Alexios Zavras
  • Armin Tanzer
  • Brandon Lum
  • David Edelsohn
  • David Kemp
  • Dick Brooks
  • Gary O'Neall
  • Jeff Schutt
  • Jennie
  • Jordi
  • Joshua Watt
  • Kate Stewart
  • Keith Zantow
  • Kevin Cressman
  • Marc-Etienne Vargenau
  • Maximillian Huber
  • Meret Behrens
  • Norio Kobota
  • Rose Judge
  • Sean Barnum
  • Takashi Ninjouji
  • Vedant Jolly
  • William Bartholomew

Agenda

  • Usage Profile Introduction
  • Build Profile Merging
  • Core Profile - Relationships, Missing fields
  • AI Profile (if time permits)
  • Dataset Profile (if time permits)
  • Licensing Profile (to be scheduled)
  • Security Profile (to be scheduled)

Usage Profile Presentation

  • Both parties (package supplier + product maker) must control the Terms and Conditions of using the Delivery
  • Information to be delivered:
    • OSS License they are using
    • Build options and test info
    • Terms of use for deliverables
    • Expiration date and time OR expiration event
    • When and Who created this document (UsageProfile BOM)
  • Conditions to apply the profile: 1) UsageProfile can be applied and integrated into Deliverables, Distribution and Packages 2) UsageProfiles can express the priority of the relationship between each profile
  • William: concern about the usage of "profile" as it has a different definition elsewhere
  • Brandon: How can we leverage what the build profile is already doing?
  • Model diagram explanation:
    • Want usage profile to have licensing info for each package (spdxid, license declared and concluded)
    • Discussing whether it is possible to use references to SPDX generated by the Build Profile
      • Brandon: Usage object describes the package; when we have a build element we have relationships from the build element to the package. Technically linking to build info should be implicit because derivable from package relationships but not sure
    • Brandon: Build element to package describing, possibly with a relationship to usage element.
    • Kate: Not profiles but elements: Usage element and Build elements
    • If we use relationships to express relationship between usage element and package element, does it confuse computational making a dependency graph?
    • William: relationships have a much broader usage; if it makes sense to have a specific relationship type or more general one it's fine
    • Sean: Distribution deliverables are intended to be new elements; is this correct (Usage elements)? Are these new elements within core? (Usage, Distribution and Deliverables)
    • William: these would be part of lowercase namespaces
    • Japan team thinks that if we can substitute these elements names with another element we will replace the element name (i.e. package is package element; artifact has similar meaning to usage element) - we will continue to discuss
    • Expiration date - might not be a definite date and time, in that case use expiration event
    • When and who created the usage profile: creation/author info
    • UsageProfile element has SPDX ID so want to have relationship between each profile (Operator like definition in relationship field)
    • PR is being prepared for this; more discussion in the near future
  • Likely have a call next Monday evening to discuss interaction between Usage and Build profile (will be Asia friendly time)

William site demo

  • Experimentation with site generation and how we will represent different things on the site
  • Generated with mkdocs but the source documents for this demo have been manually edited
  • We will separate scenario documentation from reference documentation (i.e. getting started section)
  • Different pages for different use cases; within that page documentation of different scenarios and workflows - non spec content supports how you would use it
  • Reference section is generated documentation from schema (coming from tool Sebastian wrote)
  • Generating inheritance hierarchy
  • How to handle inheritance properties:
    • Only see properties unique to particular subclass
  • Hover capability for brief descriptions
  • Syntax section for different formats
  • Does it make sense to separate the concept of syntax from different examples?
    • The example is how we demonstrate syntax when William first put it in
    • Maybe we want abstract syntax example with placeholder values for non-fixed values
    • Could also have context examples i.e. here is an example of an npm package
  • Alexios: we need to represent what gets changed via profiles. i.e. when you have something that is optional in the example but cardinality changes based when using a certain profile.
    • Might want to flag properties changed in different profiles
  • Implementation: just the properties are generated out as their own file; element class embeds that as a snippet and annotation class embeds exactly that same content as a snippet but on the element tab
  • Can we merge this to main repo? This is faux generated stuff, we need to have the correct info in it first (Alexios will make it happen with Williams help :)

Open Table Questions

  • Do we expect element to be the only class that has ids? Sean: everything has to have IDs. Every class needs a globally unique id if we are going to merge "documents" together
  • Is license a child of element or will there be another class with an ID?
  • In 2.3, simple licensing info was parent of listed license and extracted license and needed an ID
  • Sean would assert all classes must have unique IDs - as soon as you take local content in scope with other content eveything needs ID.
  • Thread going offline for this

Build Profile

  • Build profile PR is merged
  • AI and data has a few PRs that are ready to be merged in.
    • When we merge them they're not done; they are just referencable from the rest of the model and more accessible for other profile users. Expect lots of PRs for fixes
  • In discussion from build relationships might be a change to the model

Relationship Model Diagram

  • https://docs.google.com/spreadsheets/d/1yb49TkcR_dVEH_k_iOcBjNZbYDjkmd0HVweIuDpS9eg/edit#gid=2026590090
  • Software Dependency relationships: Link type, scope and requirement
  • Dependency link type (noAssertion, static, dynamic, tool, other), Dependency scope (build, dev, test, runtime, other); DependencyRequirement (noAssertion, optional, required, provided, preRequisite)
  • Why did we decide to replace BuildToolOf with DependsOn?
    • If we use depends on we consolidate relationships
    • Another reason: if you look at matrix of environments it multiplies the relationships where you can categorize the different relationships across the different dimensions
    • Basically simplifying relationships by reducing the total number of relationships
    • Keep contains for migration (especially given NTIA connection) - opinion that it is semantically distincy from DEPENDS_ON and must stay.
    • If something is a dependcy do you need DEPENDS_ON and CONTAINS?
      • Gary: that would be the ideal way to represent that. William: I agree, one describes logical tree and one describes physical tree
      • Gary: CONTAINS relationship gets abused when they should be using something finer grained
      • Sean: Don't always need both; There are situations where contains makes sense where depends on makes no sense. i.e. snippet won't depend on files but is contained within in
      • Depends on statically vs dynamically linked: statically linked: have depends on but not contains
  • Brandon: distinguishing between physical and logical. Some pacakges defined as logical entities but they use contains relationship. Is there a way to put some restrictions on this?
    • Kate: As we write up the description of the field we should clarify this
  • A lot of these changes make sense and are logical but they will be a nightmare for tools updating from 2.3 to 3.0. We need good rationale and may need some finessing
    • DEPENDENCY_MANIFEST_OF will be almost impossible to upgrade
  • DESCRIBES - a lot of documents have this but Gary thinks there's a clean migration to get rid of it since we have Bundle with a root element property
  • DISTRIBUTION_ARTIFACT --> OUTPUT_OF: impossible to upgrade; OUTPUT_OF should have a scope (i.e. output of development, build or runtime)
    • Maybe we add Purpose on property of relationship
  • is ARCHIVE_OF redundant with GENERATES? Gary thinks they are semantically different - we will keep
  • Is GENERATES equivalent to OUTPUT? Gary OK removing it; Brandon counter: source file generates binary
    • Two scenarios: Tool used to GENERATE something which is synonymous to OUTPUT relationship but also file generates binary which would use GENERATES where OUTPUT doesn't seem right.
    • FILE_ADDED, FILE_DELETED, FILE_MODIFIED: relationships from file to package. FROM has one less file than the old one
  • PACKAGE_OF --> DEPENDS_ON: leave open for further research from Gary
  • PREREQUISITE_FOR --> DEPENDS_ON with Type Prerequisite
  • INPUT_OF: Do we want meaning of relationship to also encapsulate element it is describing?
    • William: better having less relationships unless there is a semantic difference between them. Better for graph query.
  • GENERATES --> OUTPUT_OF with scope behind it? The problem is the metadata: if you have a yaml file that generates a parser code, the parser code is not an output of the yaml file it's an output of the tool and not the metadata.
  • Can we replace GENERATES with build element?