Yes, that’s the point.
According to the data model, the transfer ID does not belong with the data specifier:
In the old GUI tool the transfer ID is not explicitly shown, but that is probably a mistake. Let’s have a separate column for it; I am going to edit my post above accordingly. Note that on CAN (both CAN 2.0 and FD) the transfer ID wraps around 32; on other transports it grows continuously (the background and motivation are explained in the alternative transports post).
I hear that the jet palette is out of fashion now? If not, then let’s just use it. Otherwise whatever you find appropriate.
Both. I suggest they both should have the same hue but different lightness so that the background is light and the text color is dark:
Coloring just the text seems insufficient because the color becomes barely distinguishable against the white background.
At a first glance it’s sensible except that you can’t say just “time”; it is insufficient because there are many incompatible ways of timekeeping. The timestamp should be converted into other time systems by the backend so the JSON model should account for that (so it’s not just “time”, it should be at least monotonic time (always available), TAI time (optional), and application-specific time (optional); the frontend can convert from that into appropriate formats). Also the transfer ID is misplaced but I wrote about that already.