Define the Mapping logic from arbitrary input columns to standard attributecode columns

[DennisClark]

Define the Mapping logic from arbitrary input columns to standard attributecode columns

[DennisClark]

Arbitrary input columns can mean the columns we can expect to find in:

• A product Inventory or BOM report/file (spreadsheet)
• A product diclosure list (spreadsheet)
• One or more nexB FOSS products - e.g. Scancode TK and vulnerablecode

[chinyeungli]

as nexB/attributecode#1 , the current tool doesn't have any requirement for the input columns. All the fields and columns are collected and whether to display or not in the attribution output depends on the template. Having a mapping logic is good, but different projects/products/teams may have different input and/or different desire output. It may be hard to pre-defined the mapping logic? On the other hand, perhaps a well documented procedure and examples is a better approach than a pre-defined mapping logic?

[mjherzog]

I think that the question here is whether mapping fields from input to output should be in a mapping x-ref file, in the Jinja template or both. This seems to be worth some pro/con analysis because we want AttributeCode to be the Attribution engine for all of our products. We are also at a point where SBOM generation and Attribution generation may fork?

[chinyeungli]

This issue was from attributecode and no longer valid as the attributecode is migrated to aboutcode-tk and therefore follows all the requirement and spec from aboutcode toolkit