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

Technical Team/Minutes/2019-10-18

From SPDX Wiki
Jump to: navigation, search

October 15, 2019

Attendees

  • Gary O’Neall
  • Alexios Zavras
  • Philippe Ombredanne
  • Kate Stewart
  • Nisha Kumar
  • Steve Winslow
  • Jim Hutchinson
  • Rose Judge

JSON / YAML Formats

  • Working on tooling for JSON and YAML – Java and Python libraries both have prototype implementations
    • started discussion in Dec. 2017 - yes, did want to support, challenge was making it real. Lot of discussion - multiple formats helps adoption. YAML, JSON & XML got the nod.
    • Initial prototype done in Java tools to show all 3 formats.

Python tools was enhanced over summer to include JSON & YAML

  • Several issues have been tagged with “new format” label
  • Issue #143 - which of the two terms do we use?
    • proposal is go with TagValue spdxVersion: SPDX-2.0.
    • RDF is: spdx:specVersion.
    • Consensus is to got with TagValue for JSON, YAML, and revisit merging this in 3.0
    • Alexios: How was SPDXJSONExample-v2.0.json generated - has both spdxVersion & specVersion in it? Gary - agree - its a mistake. Will fix.
  • Steve: Sample JSON document - looking at fields part of creation info section.
    • Structuring of Document Creation info, in example creation info is separated out
    • Discrepancy between model and way document is structure with SpdxDocument vs Creation Information. Sections in spec are not aligning with model in this area, and should be clarified.
    • Any representation that includes a heirarchy should include reference to model.

For YAML & JSON - it is following model description.

    • Steve - For 3.0 - this is an area to revisit the UML model & spec. Things more related to license list should also be revisited. Want to make sure we have coherence to the Specification and the model.
    • Gary - Once we’ve agreed what’s in 2.2, we need to do a review of the model to make sure it includes the data.
    • Rose: who owns creation info, if multiple tools? Gary - can have multiple creators and tools.
  • Issue #115 - JSON file structure design.
    • documentDescribes - change structure to have key file or package
    • Steve: For files not associated with package? Heirarchy of elements describes - required relation in RDF, but implied in TagValue. If more than one package or set of files. Kate: This was way to structure the document, and where to start (top level items).
    • Gary: Resolution: adopt Xavier’s approach for structuring. Steve is agreement. (others crickets)
  • Issue #114 - JSON, YAML, and XML do contain namespace.
    • its in JSON - line 20 has spdxDocumentNamespace —> change to documentNamespace. Note its same tool, so should be there.
    • Resolution: change the name to be consistent with the spec.
  • Issues #96 - Related SPDXelement format.
    • Line 113 in JSON has example.
    • Annotations and relations are property of element that contains relationship in JSON & YAML.
    • Rather than have relationship object contained within specific object. One advantage of way is more navigatable, but causes cycles. Lets make it just as a array of relationships, and pull it out. Steve points out that we can avoid reciprocal relationships, and resolution of relationships. With the current approach, can’t describe some things unless object present in document.
    • Pull it out to be separate array seems to be where it goes.
    • Structure as subject element id, relationship, object element id. (subject on left side of relationship, object on right side)
    • Cleans up code to do it this way.
    • Steve - 3.0 discussion, get rid of reciprocal relationships, if we don’t need them, to simplify relationships. AI: open issue to track.
  • Issue #95 - camelcase
    • Nisha points out she hasn’t seen XML parsers having issues dealing with lowerCamelCase.
    • Gary and Kate like the consistency between RDF, JSON, YAML, XML.
    • Gary for tools it is a lot of work to do custom coding. Simplifies code.
    • Alexios notes reference #143.
  • Issue #55 - no new issues raised.
  • Next Steps: merge in examples as is. Then pull requests against to resolve issues.

Future discussion: how to represent in Specification.

Retrieved from "https://wiki.spdx.org/index.php?title=Technical_Team/Minutes/2019-10-18&oldid=4753"