W3C

Automotive Working Group Teleconference

12 Nov 2019

Attendees

Present
Peter, Ulf, Magnus, Daniel, Ted
Regrets
PatrickL, Glenn, Gunnar, Benjamin
Chair
Peter
Scribe
Ted

Contents


Continue Rules discussion

Ulf: one idea is when larger pieces of change requests are submitted, ideally based on previous discussion within the group, if it is more right than wrong it should be accepted
... there may be pieces that make further refinement, lodging new issues for discussion
... one argument for this model is to avoid work getting stuck
... typically the commenter with the objection needs to revise for acceptance
... comments are welcome of course
... it can be frustrating and discouraging at present

Peter: some of the comments are difficult to interpret
... how do we determine how to handle opposing view points?

Daniel: you can make a concrete proposal and then work on that piece of the spec

Magnus: in one way it is good to get submissions and get them in. it is a draft after all so agree erring on allowing may be better
... on the other hand, we may have special interests against specific pull requests
... how to tell the situation we are in?

Ulf: there will be diverging views for sure

Magnus: we had same situation with VW pull requests outstanding since last Spring

Daniel: there were comments on that pull request that weren't answered, sometimes discussed on WG call
... we can mark things on merge

Magnus: we can set a TTL on pull requests. if there is no feedback within a timeframe it is up for decision to accept or reject

Ulf: we do not want them hanging
... what is the criteria for rejection

Ted: what Ulf described is a viable path provided issues are create for objections raised. another would be smaller pull requests. we can also accept some commits for a PR and leave others outstanding for subsequent PR and discussion
... we have a minimum amount of time to review PR, we should define a max too

Peter: how about 14 days for maximum?

Ted: ok with me with exception of August and December

Magnus: work schedules can get in the way, 3 weeks maybe better

Peter: OK
... then what? what is our process?

Ted: announce to WG intention to decide and next WG call, encourage comments on PR
... decision will be either except with reservations noted and corresponding issues created, accept some of the commits, reject

Pull requests resolvement(315,314,311)

https://github.com/w3c/automotive/pull/314#partial-pull-merging

https://github.com/w3c/automotive/pull/314/files/8f3154b3731381922444dd0ae51cb16bb2604593

Ted: splitting doc is unrelated to PR and a separate issue

Magnus: that should be discussed and a separate PR

Ulf: agree, if it makes sense we can do later as Ted commented
... most of the changes were to core, transport doc mostly examples and updated to reflect

Daniel: let's use the proposed rule from earlier, announce intent to resolve next week and accept PR as is
... subsequent issues and PR can be made
... structural changes may happen frequently

Peter: structural issue at this stage not enough to block

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

Daniel: the taxonomies are just examples, core issue is whether the access method can handle it
... I still think we should do more than "could or may"

Peter: for anything other than vehicle signals, taxonomy needs to be clear

Ted: the group is clear in commitment to VSS for vehicle signals. for other domains what we need are general rules for data models to follow to be compatible with Gen2

Daniel: as an automotive group, it should have some relation. you need to define what to expect for sure. VSS is an example and can have private branches
... for the domains I would hope to have link to vehicle work. media doesn't have to be in VSS but needs to be described and a common format - JSON with a data structure
... it can be defined elsewhere but how to link them?

Ted: registry and service discovery for client applications to me makes more sense than a large single tree. we kind of went through this with JLR some time ago, wanting to encapsulate everything in VSS. we want to be able to support additional data domains created elsewhere but exposed as services within the vehicle if they follow our taxonomy rules

[Ulf shares screen]

slides

Ulf: this is for a related but separate API for supporting more dynamic registry
... this is not a frequent operation like a new playlist. it would require a different level of security
... ability to add/delete services besides what Gen2 provides and based on architecture
... routing to pertinent service based on tree

Daniel: best example is GraphQL, you do not want to expose the service underneath necessarily
... you can support legacy services via abstraction

Ted: but can be unwieldy in-vehicle apps for JSON, getting back all data and more than you need can be a performance problem

Daniel: that is a bad request then and you can have safeguards on your service
... you can have things separate but define the relationship at the top level, how it relates to the vehicle

[also want understanding of registry from ViWi within group]

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/22 15:54:51 $