Add vendor field, remove x-tool guidance

[nickelpro]

Fixes: #5

Unsure if it's desirable to allow this inside requirement as well. Conservatively I'm against it. If it's absolutely necessary we can add it later. Also on the fence about platform, but I think that allows CPS to be extended to environments the spec doesn't currently encompass.

[mwoehlke]

I am not convinced there is consensus on the name. See #5 (comment).

[mwoehlke]

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.

[mwoehlke]

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.

[mwoehlke]

Per discussion in #5, are we okay with extensions?

[nickelpro]

Per discussion in #5, are we okay with extensions?

Vendor is the common name, already used in the P3286 manifest format we use for module support and elsewhere. I don't really care one way or another, but if it's unmotivated bike shedding (ie, not "this collides with usage from Z"), I'd rather keep vendor instead of introducing one-more-convention for how vendor extensions are described.

The key name is irrelevant, consistency matters.

[mwoehlke]

I remain, as always, opposed to "vendor". Aside from being ungrammatical for this usage, if you were to tell me without context and without prior knowledge of other usage that there was a "vendor" attribute, I would expect it to mean 'that person or entity which provided the software package'. Moreover, that seeming like the sort of thing CPS might want to express at some point, I am loathe to expend the most obvious name for the attribute on something which — again, without external context — I would never expect to be used as is proposed here.

"Extension", in software, is defined as "an optional component that adds functionality". That is the purpose of the proposed attribute, therefore, that is the correct terminology to use.

[dcbaker]

I prefer "extension" to "vendor" but I'm fine with either and am in favor of painting the bikeshed more than what color we paint it. you have my a-b on either of those options FWIW