Automotive Working Group Teleconference

04 Dec 2018


Benjamin, Ted, Mike, Rudi, Don, Peter, PatrickB, Glenn, Daniel, Ulf, Hira
Rudi, Ulf



- Wildcards in url (see Transport ch

- Identical payload on all transports?

- Data model:

o Should all VSS features needed be specified in VSS, or are there W3C specific features to be specified in this spec only?

o At what detail level should VSS be described here?

- Check interface_gen2.html to see what is mentioned here that should be brought into spec docs

o In which document?

o Own chapter, subchapter, or in existing chapter?

- Improvement on current chapter layout?

Specification update

Ulf: as you know I have created two documents, core and transport, that was inspired by conversation at the face to face
... also taking M2M as an influence
... certainly a fair amount of rework will be in order but this should serve as a starting off point
... for the transport messages I tried to provide examples
... there are sections brought in from VISS and ViWi

Wildcard handling

[screen share was on new document and switched over to VISS for wildcard section]

Ulf: I adapted methodology and maybe worth a separate, more detailed discussion
... path is dot limited and draws from example in ViWi but it is not very feasible to have wildcards in HTTP URIs
... this seems wrong however do not have a solution

Ted: I don't have a solution either but wonder about using either extra path info or querystring with the wildcards

Rudi: how about having it in the body?
... path has a different meaning for VSS

Joakim: in sparql you can have a querystring with wildcard in the URL

Mike: multiple wildcards are sometimes supported in URLs

Ulf: that could be a solution
... path could replace . with /s and always be a 1:1 mapping

Benjamin: you propose a 1:1 mapping of each node, one signals corresponding to a URL and that differs substantively from the sparql querystring
... I agree having a URI model for VSS would be practical

Joakim: I was just drawing from sparql on having a wildcard
... it might be able to do filtering

Benjamin: sparql might be a bit computationally heavy but could draw from that model

Ulf: perhaps we should give some thought

Action Ted to create wildcard issue in github

Payload consistency across transports

Ulf: in my examples I am returning the same payload in both access methods
... sometimes you receive redundant information. unsure how wildcards might cause complexities/differences of wildcard handling in different transports
... we need to have the method in WSS whereas it is built into payload
... there is a value to having them identical. a client can be agnostic to what transport it goes over

Ted: in HTTP there are only headers sent, no request body for GET. POST payload is name/value pairs and PUT can be essentially anything in body

[it might be possible to send a body and HTTP server would ignore, reaction might vary and trigger error]

Ulf: many VISS methods map to HTTP but unsure how to handle case of subscribe

Peter: perhaps we raise this as an issue in github as well
... with our previous implementation we had some inconsistencies
... I understand the goal but it might not be attainable

Ulf: you could have $subscribe or $token (to handle auth) within the URI

Data model

Ulf: Should all VSS features needed be specified in VSS, or are there W3C specific features to be specified in this spec only?
... we have tokens and access restriction model in VISS and somewhere we need information on which nodes require token
... that could be placed within the node itself, denoting what access is required
... it might be difficult to represent adequately in that context
... but if we do try to represent it there then

Ted: VISS' getMetaData returns an app the signals it is permitted (and/or available on vehicle) based on the token, requires app to handle possibly a subset of what is desired, degrading gracefully. A given app probably would not even be installed if it won't be given the bare minimum of needed signals
... having core signals an app can expect to be available, what is deemed personal identifying information, restriction categories would certainly be of benefit in setting developer expectations so there is an argument to expand VSS

Ulf: that is related but also wonder more broadly if there might be other funcationality that we should represent in VSS itself

Rudi: VSS supports notion of an overlay with additional information being augmented and could vary for instance by OEM
... we have used that already for representing CAN frames specific to a manufacturer

Ulf: technically it is possible but it worth clearly specified capabilities coming from the access method?

Rudi: if separate from VSS that could cause some confusion. maybe a custom branch in the same repository that has those extensions

Ted: as noted there are benefits to having expectations for signal access in VSS, what may be available without a token for any app.
... in addition to VSS being able to expand, it can also override and have reduced data
... as to higher level discussion, what should be added into VSS that might be W3C specific should be considered on a case by case basis

Ulf: we should figure out the appropriate level to expose this information in the main README.md or an alternate for W3C extensions

Daniel: I would prefer one specific document to reference

Benjamin: we discussed granularity in VSS, we were inspired by WoT thing description and can have different templates of examples of how to extend
... these extensions might not be restricted to your private domain but shared

Ulf: my conclusion is we would need to ensure VSS documentation stays in line

Peter: yes, we coordinated with GENIVI extensively for VISS

Ted: we should expect the same as all three maintainers (Rudi, Benjamin and Daniel) of that GENIVI repository are on this call

Daniel: we are open to suggestions as long as there is improvement in the end

Ulf: we should start to look at the interface document that PatrickL has started. I find it very good
... we should see how to draw from it and put in these two new emerging documents

Ted: we should have the benefit of PatrickL next and maybe suggest to him as agenda topic

(or following as me might have too much backlog right after vacation)

Work Description

Ulf: I would like some guidance on how we handle contributions and coordinate ourselves

Rudi: is that an existing problem, git is well suited as is the github capabilities

Ulf: I think it best to have clear assignments to avoid duplicating effort or have things ignored

Peter: I see your point but previously it wasn't an issue. the main contributors did the bulk of the writing
... we did most of the discussion in issues. if there are more people who want to contribute then we might want more conventions

Daniel: my suggestion is smaller commits for easier and quicker review, it also reduces conflicts

Ted: feel free to indicate on call or in github issue if you are inclined to write up a proposed solution to avoid duplicating effort. issues that don't reach conclusion or in limbo would become call agenda topics and get discussed and potentially assigned

Daniel: Rudi could you take a look at Ulf's outstanding pull request as we are trying to decide if that belongs on VSS v1 branch

Rudi: Ok

Ulf: parting comment is to encourage others to write


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: 2018/12/05 12:49:12 $