registrystack / registrystack/registry-stack
Decide the casing of the codelist allowed_outputs key
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 57m
- Merged PRs (30d)
- 128
Description
Found while verifying adopter-facing configuration documentation against the v0.21.0 release.
## Inconsistency
The codelist artifact grammar uses `allowed_outputs` (snake_case):
```yaml
id: urn:gov:example:codelist:region-map
version: '1'
entries: {SOURCE-A: REGION-NORTH, SOURCE-B: REGION-SOUTH}
allowed_outputs: [REGION-NORTH, REGION-SOUTH]
```
Every other multi-word key across the bundle and runtime grammars is camelCase (`assuranceProfile`, `bundleDirectory`, `maximumFileBytes`, `holderBoundBatchMaxSize`, `acquisitionCapabilities`, ...). `allowed_outputs` is the lone snake_case multi-word key an adopter writes, and it is easy to mistype as `allowedOutputs`, which the closed grammar rejects as an unknown key.
## Suggested fix
Pre-1.0 this is still changeable: either rename to `allowedOutputs` for consistency, or, if the codelist artifact grammar is considered frozen with the Version 1 contract, document the exception explicitly where the artifact is described so adopters stop tripping on it.
Contributor guide
Research direction
Start by locating the codelist artifact grammar and the adopter-facing configuration documentation described in the issue, then compare allowed_outputs with the other multi-word keys in the bundle and runtime grammars. Done means the casing decision is recorded and either the relevant grammar references are updated consistently or the exception is explicitly documented for adopters.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100