JSON/AVRO schemas for RDM Darwin Real Time Train Information

[ceri....@gmail.com]

Hi folks.

Just as a double check, does anyone know of any JSON schemas for the JSON/AVRO kafka feeds? The docs in RSPS5053 imply that they're available under "Reference material", but while that does have a schema for the outer layer of JSON (ie: what was originally the stomp headers and body in the previous implementation), I can't find anything that describes the data in the bytes field. 

Thanks,

[Peter Hicks]

Hi Ceri

On Saturday, 30 August 2025 at 12:14, ceri....@gmail.com <ceri....@gmail.com> wrote:

Just as a double check, does anyone know of any JSON schemas for the JSON/AVRO kafka feeds? The docs in RSPS5053 imply that they're available under "Reference material", but while that does have a schema for the outer layer of JSON (ie: what was originally the stomp headers and body in the previous implementation), I can't find anything that describes the data in the bytes field.

Although I don't use the Darwin feed via RDM (no problem with it or the data, we've just got other connectivity), from the 'Preview' option on the RDM, it looks like the JSON is as you say  simply the headers on the messages coming from Darwin itself.

I'm not aware of any official schemas for the AVRO or JSON format data - the XSDs referenced in RSPS5053 are the canonical ones.

I imagine somebody thought a good idea to convert the messages from XML to JSON and AVRO format to make it 'easier' to consume.  Whilst that may be true for languages which don't have support (e.g. external libraries) for XML parsing, almost everything in common use these days does​, so the lack of a schema ironically makes it more difficult as you don't have anything to flag up breaking changes!

If you were asking for advice on what to do, I'd suggest you consume the feeds in XML format via RDM.

Peter

[ceri....@gmail.com]

Hi Peter,

Fair enough. I've ended up manually defining types for the json representation (I'm using rust, which doesn't have convenient XSD support). The irony is that the whole point of AVRO is meant to be that it a) has well defined schemas and b) a compact binary representation, and I can't see we get either here.

I've also noticed that the JSON has grouped up the `PP` and `IP` elements within schedules, rather than preserving the order in the original XML. It does make me wonder a few things about the development process. But I've left some comments on the RDM discussion section, where they'll hopefully see them.

Thanks,