Skip to content

Add metadata annotation keywords #40

Description

@crmne

Goal

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:

string :email,
  title: "Email address",
  description: "Primary contact email",
  default: "user@example.com",
  examples: ["alice@example.com"],
  deprecated: false,
  read_only: false,
  write_only: false

Complex schema nodes should also support metadata from inside the block, where long annotations read more naturally:

object :account do
  title "Account"
  description <<~TEXT.squish
    Billing account metadata used for invoices and subscription state.
  TEXT
  default({ status: "active" })
  examples [{ id: "acct_123", status: "active" }]
  deprecated false
  read_only false
  write_only false

  string :id
  string :status
end

Arrays should follow the same current-node rule:

array :events do
  description "Chronological event list"

  object do
    description "Single event payload"

    string :type
    integer :timestamp
  end
end

Composition blocks should support annotations on the composition schema itself:

any_of :identifier do
  description "Accepted user identifier formats"

  string description: "Username"
  integer description: "Numeric user ID"
end

Reusable definitions should support annotations too:

define :address do
  title "Address"
  description "Reusable postal address schema"

  string :street
  string :city
end

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.
  • Block-level description satisfies the use case from Feature request: description inside the block #21.
  • 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions