Design Goals

This page explains the rationale behind Validation Rules (ELCL-VR). It is informative and intended to provide context for the intended use cases, design boundaries, and trade-offs made during development.

Goals

Validation Rules were designed with the following goals in mind:

  • Minimize boilerplate code Cover the most common validation tasks directly, so applications do not need to reimplement repetitive checks for structure, types, and basic constraints.

  • Integrate naturally with ELCL Use the same syntax, naming rules, and overall style as ELCL, so validation rules feel familiar and remain easy to read and write.

  • Enable basic versioning Support forward- and backward-compatible configuration schemas, allowing validation rules to evolve alongside applications.

  • Be explicit and predictable Favor explicit declarations over implicit behavior, following ELCL’s design philosophy. This makes validator implementations easier to write, test, and reason about.

  • Support composition Allow applications composed of multiple modules to define independent validation rules for their own configuration subtrees, without global coupling.

  • Allow selective ignoring Permit parts of a configuration to be excluded from validation when checks must be handled manually or by application-specific logic.

Non-Goals

ELCL-VR deliberately does not attempt to:

  • Embed or execute application logic within validation rules.

  • Perform application-level checks, such as verifying that files exist or that network resources are reachable.

  • Provide application-defined or dynamically extensible constraint languages.

These concerns are intentionally left to the application layer.

Guiding Principles

The design of ELCL-VR follows a small set of guiding principles:

  • Keep validation declarative Rules describe what is valid, not how validation is performed.

  • Prefer simplicity over completeness Not every conceivable validation feature is included; the focus is on common, broadly useful constraints.

  • Support interoperability The same validation rules should behave consistently across different parsers and platforms, even if their internal implementations differ.

Together, these principles aim to strike a balance between expressive power, implementation simplicity, and long-term maintainability.