nmfta-repo / nmfta-opentelematics-api

API Blueprint for Open Telematics API
Apache License 2.0
13 stars 6 forks source link

add more log event types #83

Closed BenGardiner closed 5 years ago

BenGardiner commented 5 years ago
BenGardiner commented 5 years ago

There are some problems with executing the changes as-described in the feedback we received

for day log event:

  1. ELDs are required to record many log events ; but not a Day Log Event. If we required these objects in the OTAPI then the bridge implementations would need to calculate them on request. This seems like a case where all the data for these objects is available already in a given day's set of event log records. i.e. day end log records can be derived/calculated by processing a set of event records from a given day.

for status fields and new types:

  1. JSON schema doesn't do object inheritance. MSON does but any generated code from the result will require 'casting' to types based on field values. Which ends up looking like the same code with an overloaded type anyways. So there isn't much to be gained by creating a type hierarchy of event logs. Having a single event log type with the superset of all fields in the types should work because there is much shared among the log record types.

  2. At least one of the TSPs participating uses a single overloaded data type -- if we went with an object hierarchy their bridge implementation would have to do the value checking and casting mentioned above. Because the set of fields among the different event log types is very common, it is simpler for a TSP that does implement a hierarchy to cast (-up) to the common type

BenGardiner commented 5 years ago

I propose that we take the alternate approach framed in the previous comment