Module validate 

Checking a payload against the parts of the OCPP specification the types themselves cannot carry.

Most spec limits are in the type: a field the schema bounds at maxLength: 20 is a heapless::String<20>, so an over-long value is rejected at construction and never reaches the wire. Two categories escape that:

• Bounds too large to inline. A string bounded above 512 characters, or an array above 16 elements, would make every message that contains it enormous by value, so it is not stored at its spec ceiling. Under the alloc feature it becomes a plain alloc::string::String / alloc::vec::Vec, which has no bound at all; without alloc it is a heapless collection at a caller-chosen capacity, which may sit either side of the spec’s. Either way the specification’s own limit is no longer enforced by the type. AuthorizeRequest::certificate is one: maxLength: 5500 in the schema, a growable String in the alloc build.
• Constraints no collection expresses. minItems (usually 1, i.e. “must not be empty”), minimum/maximum on numbers, and 1.6J’s multipleOf on charging limits. A heapless::Vec<T, N> can say “at most N”; it cannot say “at least one”.

Validate covers exactly those. It is implemented for every generated message and nested type, recurses through nested structs and arrays, and reports the first violation with the JSON path that reaches it:

use ocpp_types::v201::AuthorizeRequest;
use ocpp_types::v201::common::{IdToken, IdTokenEnum};
use ocpp_types::validate::{Validate, ValidationErrorKind};

let request: AuthorizeRequest = AuthorizeRequest {
    certificate: Some("-".repeat(6000)),
    custom_data: None,
    id_token: IdToken {
        additional_info: None,
        custom_data: None,
        id_token: heapless::String::try_from("ABC123").unwrap(),
        r#type: IdTokenEnum::ISO14443,
    },
    iso15118_certificate_hash_data: None,
};

let error = request.validate().unwrap_err();
assert_eq!(
    error.kind(),
    ValidationErrorKind::TooLong { len: 6000, max: 5500 },
);

What it does not check

Only what the JSON schemas state. Cross-field rules from the specification’s prose (a TransactionEventRequest with eventType: Started must carry a triggerReason, and so on) are out of scope, as is anything about the caller’s own CustomDataType payload or 2.x’s deliberately untyped DataTransfer.data – the spec constrains neither, so neither is visited. Validating those is the caller’s, and nothing stops a caller from implementing Validate for their own payload type.

Validation is never automatic: nothing on the serialize path calls it, so a payload is checked exactly when you ask for it. Sending is the natural place — an over-long field comes back from the peer as a CALLERROR you cannot correlate to a field, whereas ValidationError names it.

Structs

ValidationError

A schema constraint that a payload broke, and the path to the value that broke it.

Enums

ConstraintClass

Which of OCPP’s two constraint categories a violation falls into, and so which CALLERROR code answers it.

PathSegment

One step of the JSON path to a failing value: an object key, or a position within an array.

ValidationErrorKind

What was wrong with the value.

Constants

MAX_PATH_DEPTH

How many path segments a ValidationError carries before it starts truncating (see ValidationError::path_truncated).

Traits

Validate

A type that can be checked against the constraints its schema states.

Functions

check_max_f64

Rejects a number above its schema’s maximum. NaN passes, as in check_min_f64.

check_max_i64

Rejects an integer above its schema’s maximum.

check_max_items

Rejects an array longer than its schema’s maxItems.

check_max_length

Rejects a string longer than max characters.

check_min_f64

Rejects a number below its schema’s minimum.

check_min_i64

Rejects an integer below its schema’s minimum.

check_min_items

Rejects an array shorter than its schema’s minItems.

check_multiple_of

Rejects a number that is not a whole multiple of multiple, within [MULTIPLE_OF_TOLERANCE].