You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for Draft 2020-12 metadata annotation keywords on supported schema nodes:
title
description
default
examples
deprecated
readOnly
writeOnly
The gem already supports description in several places. For 1.0, it should be treated as part of the general metadata annotation model rather than as a one-off option.
These keywords are annotations. They describe the schema but do not usually affect validation.
The Draft 2020-12 output-contract issue should decide how root schema title relates to the current name concept.
DSL direction
Short metadata should remain available as keyword arguments:
Complex schema nodes should also support metadata from inside the block, where long annotations read more naturally:
object:accountdotitle"Account"description<<~TEXT.squish Billing account metadata used for invoices and subscription state. TEXTdefault({status: "active"})examples[{id: "acct_123",status: "active"}]deprecatedfalseread_onlyfalsewrite_onlyfalsestring:idstring:statusend
Composition blocks should support annotations on the composition schema itself:
any_of:identifierdodescription"Accepted user identifier formats"stringdescription: "Username"integerdescription: "Numeric user ID"end
Reusable definitions should support annotations too:
define:addressdotitle"Address"description"Reusable postal address schema"string:streetstring:cityend
Design rules
Keyword arguments stay supported for concise inline metadata.
Block-level annotation methods configure the enclosing/current schema node.
Block-level annotations must not accidentally become child properties or child schemas.
If the same annotation is provided both as a keyword argument and inside the block, the keyword argument should win unless we explicitly decide otherwise before implementation.
This current-node modifier machinery should be reusable by related 1.0 DSL work, including core comments/identifiers and content schemas, but annotation keywords should remain conceptually separate from validation constraints.
Acceptance criteria
Annotation keywords render on supported primitive schemas.
Annotation keywords render on supported complex schemas, including object and array.
Annotation keywords render on composition schemas, including existing any_of and one_of, and should be compatible with future all_of / none_of work.
Annotation keywords render inside reusable schemas under $defs where valid.
Docs clarify that these are annotations, not validation rules.
Generated schemas validate against Draft 2020-12.
Related existing issue
#21 requests description inside blocks for cleaner complex schema descriptions. This should be implemented as part of the broader annotation/current-node modifier design here, not as a special case only for description.
Goal
Add support for Draft 2020-12 metadata annotation keywords on supported schema nodes:
titledescriptiondefaultexamplesdeprecatedreadOnlywriteOnlyThe gem already supports
descriptionin several places. For 1.0, it should be treated as part of the general metadata annotation model rather than as a one-off option.These keywords are annotations. They describe the schema but do not usually affect validation.
The Draft 2020-12 output-contract issue should decide how root schema
titlerelates to the currentnameconcept.DSL direction
Short metadata should remain available as keyword arguments:
Complex schema nodes should also support metadata from inside the block, where long annotations read more naturally:
Arrays should follow the same current-node rule:
Composition blocks should support annotations on the composition schema itself:
Reusable definitions should support annotations too:
Design rules
Acceptance criteria
objectandarray.any_ofandone_of, and should be compatible with futureall_of/none_ofwork.$defswhere valid.descriptionsatisfies the use case from Feature request: description inside the block #21.Related existing issue
#21 requests
descriptioninside blocks for cleaner complex schema descriptions. This should be implemented as part of the broader annotation/current-node modifier design here, not as a special case only fordescription.