In T620#10902, @nrwahl2 wrote:

However, I'm not sure whether you wanted to include meta-attributes that can be set on a collective for the sole purpose of being inherited by a primitive (sort of the opposite scenario compared to the one above).

• On the one hand: it's cleaner and clearer not to include them, and to include only those meta-attributes that have a direct effect on the collective. We can simply ensure it's documented (maybe it already is) that primitives inherit all of their parents' meta-attributes. That implies that any primitive meta-attribute can be set on a collective for the purpose of inheritance.
• On the other hand: excluding them offloads more work to external tools. For example, if pcs is validating meta-attributes for a bundle, then it needs to check the list of bundle meta-attributes, the list of primitive meta-attributes, and maybe the list of clone meta-attributes. That's not a deal-breaker, but it requires that extra knowledge of Pacemaker behavior be built into external tools.

For the purposes of showing lists, I would think we want to show the meta-attributes that can apply directly to the thing being requested (not just inherited).

In T620#10892, @nrwahl2 wrote:

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

Running a command that generates XML on demand (which is our main goal anyway), and then parsing that, is probably easier than parsing the C code.

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.