Summary
As a package developer, in order to express that the presence of one named element makes other named elements mandatory, I would like stabilize_lst() to enforce dependent-required relationships between element names.
Details
JSON Schema dependentRequired maps a property name to a list of property names that become required whenever the first property is present. It is a cross-property constraint within a single object.
This is a plausible stabilize_lst() extension because stbl already validates whole lists and checks required names. Implementation is likely to be deferred — captured here so the design isn't lost.
JSON Schema connection
dependentRequired: { "credit_card": ["billing_address"] } → if x has a credit_card element, it must also have a billing_address element. The dependency is one-directional and triggers only on presence.
Proposed shape
A stabilize_lst() argument accepting a mapping of trigger name → required names, e.g.:
stabilize_lst(
x,
dependent_required = list(
credit_card = c("billing_address")
)
)
- Keys are element names that act as triggers.
- Values are character vectors of element names required when the trigger is present.
- Purely a presence check on names; it does not constrain the values themselves (compose with value specs for that).
Behavior
- For each trigger name present in
names(x), verify all its dependent names are also present; otherwise error, naming the missing dependents and the trigger that required them.
- Absent triggers impose no constraint.
Scope
Related conditional keywords (if / then / else, dependentSchemas) are out of scope: they are cross-property orchestration better assembled in the converter package using stbl's existing spec-evaluation machinery (stabilize_*_of(), assert_not()). dependentRequired is singled out here because it is a simple presence constraint that fits stbl's list model.
References
Summary
Details
JSON Schema
dependentRequiredmaps a property name to a list of property names that become required whenever the first property is present. It is a cross-property constraint within a single object.This is a plausible
stabilize_lst()extension because stbl already validates whole lists and checks required names. Implementation is likely to be deferred — captured here so the design isn't lost.JSON Schema connection
dependentRequired: { "credit_card": ["billing_address"] }→ ifxhas acredit_cardelement, it must also have abilling_addresselement. The dependency is one-directional and triggers only on presence.Proposed shape
A
stabilize_lst()argument accepting a mapping of trigger name → required names, e.g.:Behavior
names(x), verify all its dependent names are also present; otherwise error, naming the missing dependents and the trigger that required them.Scope
Related conditional keywords (
if/then/else,dependentSchemas) are out of scope: they are cross-property orchestration better assembled in the converter package using stbl's existing spec-evaluation machinery (stabilize_*_of(),assert_not()).dependentRequiredis singled out here because it is a simple presence constraint that fits stbl's list model.References
dependentRequired: https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.htmlstabilize_lst(); optional named properties (feat: optional named properties in stabilize_lst() #279).