Representing frames that do not parse as OCPP-J

[sepehr-safari]

v1.1 requires messageType, so a frame that does not parse as an OCPP-J array cannot be represented as a record at all: truncated frames, non-array JSON, non-JSON text. That is exactly the traffic a debugging workflow most wants to move between tools, and it was flagged as a known limitation when v1.1 landed (shiv3/ocpp-cp-simulator#216).

Two shapes I can see, both keeping raw as the carrier of the original text:

A. Relax messageType when raw is present. A record may omit messageType and the other frame-derived fields if it carries raw. Consumers treat such records as opaque: counted and displayed, never correlated.

B. A dedicated kind, e.g. messageType: "MALFORMED". Explicit and self-describing, and messageType stays required.

Either way there is a versioning question to face honestly: a trace containing such records will fail validation for consumers pinned to today's schema. Since no current producer emits them, no existing trace breaks, but per the versioning rules this looks closer to a new major than a minor. That is worth deciding deliberately rather than inheriting.

Once a direction is picked I can add the corresponding fixtures (truncated frame, non-array JSON, non-JSON text) with their expected consumer views.

[juherr]

B, from a consumer that has to turn this into a verdict.

Context: I maintain open-ocpp-tck, an
OCPP 1.6 conformance suite for CSMS implementations. It drives shiv3's simulator
against a Central System and asserts on the wire log, which is why I am looking
at moving from parsing the simulator's log lines to consuming this format.

For that class of consumer, a frame that does not parse is not noise to be
preserved for a human — it is the finding itself. A CSMS that answers with a
truncated or non-array frame has failed a test case, and the suite has to say so
by name.

That is what decides A vs B for me. Under A, "no messageType" is ambiguous
between the producer observed an unparseable frame and the producer did not
populate the field. A verdict cannot rest on an absence, so I would have to
infer malformedness from raw — which is the string-parsing I would be adopting
this format to stop doing. Under B, messageType: "MALFORMED" is a positive
claim by the producer, and asserting on it is a one-line check.

On the versioning question: both shapes break a consumer pinned to v1.1 — A by
omitting a required field, B by introducing an unknown enum value. The difference
is how they break. A missing messageType looks like a malformed record; an
unrecognised messageType looks like a newer producer, which is the diagnosis
you actually want.

Happy to be an early consumer of whichever direction you pick, and to contribute
the CSMS-side fixtures — a Central System sending a truncated frame, a non-array
JSON response — to complement the charge-point-side ones you listed.

---

_{Drafted by Claude under my supervision.}