Proposed: Cancel 31 July
Gunnar: re 7 August, agree to defer to chairs
https://www.w3.org/community/autowebplatform/wiki/Consent_Cases
https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework
Ted: a topic we should continue from last time is how to handle multiple VISS servers on a vehicle, spec says it is possible but how would developers find it and handle branches being fragmented across them
Kevin: we are in favor of keeping
it possible to have multiple in practice
... one way to deal with it is produce graphs of data a bus has
exposed to it
... we do not want to restrict ourselves
Ted: in conversations with some Tier
2s, they are wondering if they should be implementing VISS on
their control units especially if ethernet becomes the prevailing
network in place of CAN et al
...would probably still want a
main VISS server to handle auth tokens and it may be aggregating or
proxying to the ECU
...this might be a practical way to
handle after-market and different capabilities at vehicle trim levels
Kevin: we are introducing it our entertainment platform
Ulf: we are also working on an
implementation but have not gone that far yet, no client code
being written against it
... we are focusing on a single server and not distributed
Ted: we want to avoid applications needing to be customized to run on different vehicles, configuration can be external to applications and handle specific vehicles
Gunnar: it feels a little bit
like we are starting on the wrong end, trying to make things
90+% compatible across vehicles is major
... 100% would be better, how to find service addresses
... examples can be done in a guidelines or best practices
document. OEMs will have their own ideas on how to
implement
... not sure if we could conceivably reach 100%
... at some point we might want to discuss discoverability
Ted: it can be a later document indeed, a compliment to VISS spec based on dev feedback
Gunnar: agree, we should get the
core spec out first
... app developers remain involved in some sense within the
auto industry when it comes to installation of their app on a
vehicle, we can bring it down to minor tweaks
... I was in favor of the simple hostname solution and for OEM
to handle addressing on the LAN but that was not well received
as you cited
... for services to be discoverable you would need a known host
to advertise services
Ted: or within DHCP which doesn't make sense when network should be static...
Gunnar: system can know where the real servers but the applications do not, they can speak to a central proxy
Ted: we are lacking enough developer feedback at this point, hopefully will change as implementations are emerging
Gunnar: there is a security
consideration as well. access control is handled within VISS,
responding to getMetaData
... you may want to supress certain VISS servers altogether and
not have them discoverable
Ted: VISS should respond with only signals an application token is allowed to see. I agree some VISS servers should be better protected and not discoverable
https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework#Information_Models_VSS.2FVIWI
Ted: hopefully we will converge on access method (VISS/RSI convergence) but we should prioritize consistent data model between them
Gunnar: I agree
Ted: flattening then seems like the next most important, question is how to progress? For this conversation I would like Rudi, PatrickL, Ulrich, Benjamin...
Gunnar: first step would be to agree on names of things
Ted: yes, remove the tree, flat view, common names and then what should the tree look like
Gunnar: concepts, names and then grouping
Adam: this can impact ability to do wildcarding with compound names instead of sub branches
Gunnar: the tree matters as part of the concept, examples will clarify
Ulf: I am a bit doubtful that the
tree can be flattened significantly
... the present number of levels is closer to 7 or 8 and trying
to pair down to an arbitrary 3 would loose some of the benefits
and I am not in favor of that
Tim: I do quite a bit of data
manipulation. what is the motivation for flattening? it is
usually for an implementation than semantics
... people look to flatten trees to be able to get into eg a
table structure
Adam: there is an increased
number of people interested in the data for analytics
... they will likely want to concentrate on specific
branches
Gunnar: sometimes you want to
know the strict definition of what it is you are
measuring
... you might be able to find it in different places
Benjamin: i created a flat view
for my purposes, removing the tree
... it is raw material to start off with and rest will be
agreement
[adjourned]