Module validate 

Explicit validation: parse permissively, validate deliberately, construct strictly.

Why validation is a separate pass

OCPI 2.3.0 requires that “An OCPI Platform SHALL NOT reject request or response payloads based on the presence of JSON object field names that are not documented in this specification” (transport_and_format — Non-specified JSON fields). In the same spirit, and because a hub that drops a peer’s data is worse than a hub that forwards slightly non-conformant data, ocpi-kit never fails a deserialisation because a string(45) field turned out to be 46 characters long.

Instead the crate follows one rule throughout:

Parse permissively, validate explicitly, construct strictly.

• Deserialize accepts what the peer sent, as long as it is well-typed JSON.
• Validate::validate reports every violation, each with a JSON Pointer (RFC 6901) into the object, so a conformance report can point at the exact field.
• The constructors (CiString::new, OcpiString::new, …) refuse to build a value that is already out of spec, so data this crate emits is conformant by construction.

Spec: 2.3.0 §transport_and_format_json_http_implementation_guide

Structs

Validator

Accumulates violations while walking an object graph, tracking the current JSON Pointer.

Violation

A single spec violation found by Validate::validate.

Violations

Every Violation found in one object, in document order.

Enums

ViolationCode

Classification of a Violation.

Traits

Validate

Checks an OCPI value against the constraints in the specification’s property tables.