bretbrownjr commented 7 months ago

Background

From the CPS spec:

Unless otherwise specified, unrecognized attributes shall be ignored. This makes it easier for tools to add tool-specific extensions. (It is strongly recommended that the names of any such attributes start with X--, where is the name of the tool which introduced the extension, in order to reduce the chance of conflicts with newer versions of the CPS.)

Proposal

Overview

Bikeshedding aside, just make a top-level object called tool that is explicitly for arbitrary extensions.

Motivation

Grouping extensions under a known and clear place would allow for stricter validation of the rest of the document, if desired. It's possible that the recommended X-<tool> mechanism could be more officially described and potentially enforced, but it would be simpler to implement and understand to just treat an entire object in the JSON file in this special way.

Use cases that would benefit right now:

C++ modules
Experiments to support languages initially out of scope
Experiments to support software bills of materials
- Including signing information

Variants

It's possible that any object in the JSON model named tool could be treated this way. It would be less awkward in some cases to add extra fields to a component, for instance, with a tool.man_pages field compared to having to add a key-value mapping from component to values in a top-level tool section.

Existing Practice

pyproject.toml supports [tool.*] sections for extensions not covered by PEP specifications.

pom.xml has sections for "plugins".

Bikeshedding

If this is interesting and we want to consider other names for the object like vendor, this issue is open to discussion. Note that more than one object key is possible to support for this use case, though it probably will be less surprising to end users if there is consistency about this.

dcbaker commented 7 months ago

See also https://github.com/cps-org/cps/issues/5 for previous discussion