The current docs and examples imply tool.version may be absent, but the schema currently treats it as required. That mismatch forces some producers to emit guessed or placeholder values.
Problem
Producers can usually identify the tool name reliably, but not always a stable version for every integration layer. Requiring tool.version in all cases can reduce data quality.
Proposal
- Make
tool.version optional in the schema.
- Keep
tool.name required when tool is present.
- Ensure examples and descriptions stay aligned with schema behavior.
Why This Should Be Added
- It removes pressure to publish inaccurate placeholder versions.
- It aligns schema and docs, reducing producer confusion.
- It is a minimal change that preserves a compact core spec.
Compatibility
Backward-compatible relaxation. Existing records remain valid; consumers can keep treating tool.version as optional metadata.
Scope
This is a schema/docs consistency improvement for attribution metadata. It does not introduce capture protocol, storage, or transport requirements.
The current docs and examples imply
tool.versionmay be absent, but the schema currently treats it as required. That mismatch forces some producers to emit guessed or placeholder values.Problem
Producers can usually identify the tool name reliably, but not always a stable version for every integration layer. Requiring
tool.versionin all cases can reduce data quality.Proposal
tool.versionoptional in the schema.tool.namerequired whentoolis present.Why This Should Be Added
Compatibility
Backward-compatible relaxation. Existing records remain valid; consumers can keep treating
tool.versionas optional metadata.Scope
This is a schema/docs consistency improvement for attribution metadata. It does not introduce capture protocol, storage, or transport requirements.