[agenda bashing]
aftermarket thread, hesitation on being able to speak freely, notifications data model example, data model wording for chapter 4
Ted: had a small turnout last week and proposed we try to come out with wording during the call on the fly to get us out of it but didn't
Laurent: maybe with the misunderstanding cleared our original wording might be more acceptable...
https://github.com/w3c/automotive/pull/304
Magnus nominated as referree
Magnus: I got what you were
trying to do at the F2F and that you wanted to wrap into a
second layer
... I'm still quite concerned about the interoperability
... understand we want commonality on data models. VSS is what
we have settled on for signals, maybe not the best for eg
media
... the rbranch stuff could be used to bring in other types
Laurent: we want to discuss beyond VSS
Magnus: I want a data model
across OEM
... it has been awhile since I read ViWi spec. there are other
efforts to have signals standardized
Laurent: when the Patricks did
the ViWi submission they included the different data models for
different use cases
... that is what we would like to do
... VSS pages starts with kind of a mix of tooling and Make,
implementation defined data types and precise data units and
doesn't apply to other things
... it has a grammar format, #include
... this is just from the Readme.md
... vspec is VSS to me. the readme is the mixed bag
... this document can be written in a more normative, abstract
way without getting into a specific data type as it does
... types don't make sense in JSON, it is ASCII
Magnus: we want Ulf and Daniel
Ted: the other domains (media, notifications etc) can have different structures although some degree of commonality would be preferred
Magnus: agree, we don't have to force the other domains into a common structure
Laurent: what is meant by data
model was what triggered the misunderstanding as some only saw
VSS
... we use data model more as normalizing how to represent
data. vspec is the grammar for the schema here
Magnus: for me there is a difference between the data model and actual data. model is the structure you place the data
<LaurentC> https://github.com/GENIVI/vehicle_signal_specification/blob/master/spec/Media/Media.vspec
Laurent: you may want to strip out media for instance
Magnus: what you get from the car will vary by manufacturer
Laurent: ADAS is signal related, media is not. you want to learn you can get cabin data but not chasis and follow the model described here
Magnus: we are building this
interface for web developers to be able to use. if we have
different ways of describing the data and different paths
... we will have interoperability problems
... if VW describes data in a different way for how to get to
door data it would be a mess
Laurent: I need something to
point people to in order to create a vspec and he will not care
about Python and Make...
... AutoSAR is has good specs for defining services
... what services are in AutoSAR, how can I model it and leave
tooling and conversion separate
... we should achieve same quality of spec in my mind
Magnus: the W3C spec is connected
to VSS spec which describes data and how it is structured
... W3C spec clarifies how to subscribe etc
... point taken on VSS readme
... they said they are willing to do that. it is also not a
complete data model at this point
... if VSS is to be useful it needs to be extended for other
domains
... others are not as complete as VSS
... should we even define a 'high level data model' at W3C then
point out underlying data models to avoid the interop
PatrickL: reason for having that
is so filters are queries can be implemented
... you need to know the structure to be able to do
Laurent: the vspec is compiliable
and generates documents, even the spec itself
... it is important other services in the vehicle adopt
similar
... maybe this abstract higher level explanation is over at W3C
in Gen2
... perhaps I only need JSON, that is what we start off with
for ViWi, and don't need vspec and YAML plus tools to produce
JSON
PatrickL: tooling needs to have a common truth which is the specification
Ted: alternate formats for the data model are fine, JSON our choice for in-vehicle but others fine elsewhere
Magnus: VSS tooling is for
generating the tree and whether it is JSON, YAML or Ulf's
C-native isn't that implementation specific?
... when a request comes to service we are defining, response
from server would be JSON
PatrickL: depends if we want to
provide multiple service interfaces
... main reason we joined W3C was to be able to create these
data models and be able to make them available to
developers
... common description is therefore desireable
Magnus: agree, that is why we are here
PatrickL: transfer is protocol specific but let's leave that aside for now
[adjourned]