Automotive Working Group Teleconference

<scribe> scribenick: ted

<scribe> Scribe: Ted

pull request 315

Ted: I have strong hesitations about adding branches per domain to VSS, easy to predict conflicts and massive tree take a big media library for example

Daniel: from my perspective the strength we should look at multi-domain vehicle model and the relationship between them
... that metadata has value and yes you could have competing signals but there are benefits to having them in the same model

Ted: related is versioning as well, how do we identify a VSS version when there could be a mix of different vintage branches

Daniel: discoverability for developers is easier under a single tree

Ulf: it can be up to the service provider where to add, it could be within the existing tree or a branch which is a pointer
... that can be a pointer to the other tree/server
... please see my updated slides

Ted: will do

Peter: question remains for this pull request

Ted: curious if we persuaded Daniel...

Daniel: we want to build single access to a service that might cross multiple domains
... serving one point has its benefits. I'll think about it more
... it can also be at leaf level that links to a different server
... service can run somewhere else but a single service can handle auth, acl etc
... there can be more complex services behind the scene but if you don't have a common description you won't have a common understanding

[[** For vehicle signals** the vehicle domain taxonomy SHALL be the base]]

Ted: I still find grafting onto a single tree extremely awkward, we will have with media a branch with limited depth but lots of twigs and leaves. If you step back and think of a physical tree, it will be extremely lopsided. [continuing with tree analogy, this will not remain standing in a storm]

Ulf: my updated slides take that into account and would work

[Ulf's slides]

https://github.com/w3c/automotive/pull/314#pullrequestreview-313293424

Ted: criteria for having a third document versus chapters for different protocols can be done later depending on size

Magnus: agree

Peter: 315 still problematic

Ulf: I think 314 should go forward

Daniel: for 315 at least now we are talking about the same thing

Ted: per our convention, I will create a new issue on separate protocol documents for 314 and we can accept

https://github.com/w3c/automotive/pull/311

Daniel: there is already 313 for document structure

Ted: for 311, do we want to be bound to VSS2.0 or allow for the data to evolve? I believe the latter

Ulf: please make the proposed change

Ted: Ok
... I'll propose some wording

kickstarting Graph

Ted: as an aside our data task force call only has a few attendees of late and doesn't make sense as the venue for launching this graph project
we have a server at MIT, number of people gave me their public keys to connect and I installed Neo4j as candidate graph engine
how do we get this going?
[response to Benjamin's comments in thread but will elaborate there]

Ulf: probably a doodle to find another time as that Thursday one is problematic

Issues housekeeping

https://github.com/w3c/automotive/issues

Peter: there are 7 very old ones
... we should close the old ones

Daniel: with a comment, inviting people to reopen

Adnan: they definitely had a week

https://github.com/w3c/automotive/issues/275

I agree as it contradicts itself, either drop type or put any

https://github.com/w3c/automotive/issues/281

Ted: summarizes, change to VSS positioning, recalling Peter's VISS implementation experience

Ulf: we decided to support queries in Gen2 so therefore we can close

https://github.com/w3c/automotive/issues/282

Ted: while we are designing for Web Sockets and HTTP, we agreed to support other protocols and agree JSON not always the most appropriate

Ulf: ok to close

https://github.com/w3c/automotive/issues/301

Ted: agree useful but not sure how feasible it would be to provide that

Peter: CAN bus has its frames

Ted: it could be timestamped when service first sees it

Ulf: agree it is problematic, we now claiming state information?

Peter: hard problem, we may not be able to do realtime
... we can ask for more granularity on what they want

Ted: I think they clearly want signal inception timestamp
... not possible with current vehicles

Ted to take care of 275 with a small pull request

Next week both chairs absent, will hijack for graph project and send mail to those who expressed interest