Skip to content

Add vendor field, remove x-tool guidance #99

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nickelpro wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add vendor field, remove x-tool guidance #99

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions schema.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -580,6 +580,18 @@ Attribute names are case sensitive.
may use a symbolic component
to indicate availability of the feature to users.

.. ----------------------------------------------------------------------------
.. cps:attribute:: vendor
:type: map(any)
:context: component configuration package platform
:overload:

Records vendor-specific extensions to CPS metadata. Vendors should ensure the
namspace they record in the vendor object is consistent across all scopes.
Comment on lines +589 to +590
Copy link
Member

@mwoehlke mwoehlke Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Records vendor-specific extensions to CPS metadata. Vendors should ensure the
namspace they record in the vendor object is consistent across all scopes.
Records vendor-specific extensions to CPS metadata.
Vendors should ensure that
the namspace they record in the vendor object
is consistent across all scopes.


Vendors are *strongly* encouraged to record a ``version`` field in the
|package| vendor object.
Comment on lines +592 to +593
Copy link
Member

@mwoehlke mwoehlke Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Vendors are *strongly* encouraged to record a ``version`` field in the
|package| vendor object.
Vendors are *strongly* encouraged to record a ``version`` field
in the |package| vendor object.

However, it isn't clear what the intent is, here, and if you're essentially proposing that tools creating CPS files record their identity version... I'm not necessarily opposed (although if we're going to recommend that, I would much rather we do so as a supplemental schema), but I'm less convinces that should be done for the sake of "versioning" extensions. I would rather the extensions themselves be versioned so Tool A can potentially write extensions for Tool B. Maybe this is redundant, but the extension tag and namespace are already redundant any time an extension is used.

An example would also be beneficial. I actually wouldn't mind seeing a full documentation page on extensions.


.. ----------------------------------------------------------------------------
.. cps:attribute:: version
:type: string
Expand Down Expand Up @@ -659,12 +671,6 @@ Notes

- 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_<tool>_``, where ``<tool>`` is the (lower case) name
of the tool which introduced the extension,
in order to reduce the chance of conflicts
with newer versions of the CPS.)

- The term "CABI", as used throughout,
refers to (typically C/C++/Fortran) code
Expand Down