<scribe> scribenick: ted
<scribe> Scribe: Ted
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
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
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
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