zak
<scribe> scribenick: ted
https://github.com/GENIVI/vehicle_signal_specification/pull/164
Daniel: encourage people to read
the proposal in the pull request and what Sebastian has
contributed
... we can discuss more next week
Gunnar: I could clear up my view
on JSON from previous call
... we should have a single definition of what VSS is, content
and semantics
... no objection for using JSON. today we have a near-exact
mapping currently from YAML to JSON
... when we discuss the csv format, the main concern is the
full path signal name
... it is not supported today
... Gen2 is based on CSV file with plain path as to how you
address things
Ulf: I think so too
Gunnar: concerned about complete reliance on JSON
Daniel: not decided how to do it
in tooling. question is how it looks in the end and how to go
forward
... today we have VISS and start of Gen2. we also have graphql,
VSSo and number of open questions around Android
Gunnar: core question is do we
have a new concept in the source (YAML) model and does it
survive translation to other formats including JSON
... to progress that we should first clarify how to use that
knowledge
... I am always concerned about creating a specialized solution
for something and prefer generalized
... not sure you can do so much with instances, not clear it is
a position and cannot programmatically know it is a
position
Daniel: it all belongs to the
same concept. my desire was to have position at the very end
and flatten it out
... would like to be able to create a dictionary out of the
instances
Gunnar: I am partial to having it
as a real part of the model and would prefer something
cleaner
... when do you need to know instance is same concept (and
there are others)
Daniel: we need some more reasoning and examples behind it
Gunnar: proposal now has
instances
... maybe each protocol (format) decides its preferred
representation
... I keep falling back to YAML being source of truth
... either need to adopt instance concept in Gen2 or translate
for path
Daniel: csv should give idea on how to address instances directly
Ted: for VISS, our examples were based on VSS1, for Gen2 we need to be able to explain how to understand positioning, find things and represent with HTTP path and possibly querystring parameters or other to be able to address a specific instance or get back all instances of eg door
Gunnar: you can do that with wildcards. not sure query syntax creates any additional availability
Daniel: you want a REST interface to be able to get to individual doors
Gunnar: if I just want to get concept of door out of model...
Daniel: you can get everything from an instance
Gunnar: if I put a * or something else in path, I want concept of door instead of a specific instance
Ted: presently we enjoy a very clear and direct translation between YAML and JSON. appreciate positioning might be handled better for Graph and other uses and in my opinion fine if there are deviations among the formats although would prefer consistency
Gunnar: JSON translation could be
done still but maybe GENIVI VSS only produces YAML and
different formats are created for their various uses
... you get YAML from VSS and can do whatever you want with it.
we cannot anticipate others' desired translations
... we are doing that presently for CSV and JSON but it could
transition
... you could load YAML just as well in Go code
Ted: there will certainly be people
that come up with their own representations for different
formats/protocols outside of the VSS repo. to the extent we can
provide authoritative formats for the ones we care about the
better.
... one idea would to also have the VSS repo act as a registry for
alternate formats maintained elsewhere
Ted: [summary of how TPACs work with
joint group meetings and unconference style breakout sessions]
... it will be virtual this year for obvious reasons, want your
input on who else besides webrtc, wot, sdwig that may be of
potential interest
Gunnar: wonder about input on security aspects
Ted: yes and can try to bring over some hopefully for that
[adjourned]