Inconsistency: ts in setSuccessResponse but not in getSuccessResponse

[SebastianSchildt]

We found that the response to set in websocket:
https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Transport.html#wss-update
includes a timestamp (ts),

while the response to get does not
https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Transport.html#wss-read-message

(only in datapoints)

If this is a bug, ts should be added to getSuccessResponse, otherwise maybe some explanatory wording why it si there in one case but not the other.

Additionally, I think it is never defined what the ts in general (error)messages should be. I assume just a VISS server timestamp, when it generated the message?

It would be a good addition to have JSON schemas for all messages. Currently in the transport spec, it seems only certain elements and the error responses are specified

[SebastianSchildt]

@wenwenchenbosch fyi

[wenwenchenbosch]

The subscription message also just contains now timestamp inside datapoints. see https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Transport.html#authorized-subscribe:

Notification:


              {
                "action": "subscription",
                "subscriptionId": "12345",
                “data”:{“path”:”Vehicle/Drivetrain/FuelSystem/Level”, 
                        “dp”:{“value”:”50”, “ts”:”2020-04-15T13:37:00Z”}
                       }
              }

[UlfBj]

Regarding timestamp in set response, but not in get response, I think that is appropriate since in the get response there is a timestamp in the data point part of the response. The timestamp in the get response shows the time of capturing the value by the underlying vehicle system. The timestamp in the set response shows the time that the updated value was delivered to the underlying vehicle system. So my view is that the get response should not be augmented with one more timestamp.
Your suggestion that some more explanation could be added, I agree to. Basically what is said above should suffice, I think.
Also some more information could be added regarding error message timestamps, as you mention.
As well as a more consistent JSON schema part.

[SebastianSchildt]

I think it can be implemented either way, so no hard opinion, but I am not sure the argument is strong: For set actually I think the only semantic is "(local) time the VISS server processed the event", as in most systems you would not know exactly when it was "written" as that might be delegated to some lower system.
Additionally, following you argumentation, it would not make sense to have timestamps in getErrorResponse, where they currently are.

So my intuitive understanding was

• every message has a ts in the "outer" layer, signifying when the VISS server "processed" the request/answered
• the ts in datapoints have a different meaning: They show - as you described - the time a datum was last updated.

[UlfBj]

I think your intuitive understanding above provides a uniformity to the solution, which I think makes it worth considering. I will bring it up in the WG for discussion.

[tguild]

Addressed with PR 401