Automotive Working Group Teleconference

<scribe> scribenick: ted

<scribe> Scribe: Ted

Pull requests

<PatrickLue> https://github.com/w3c/automotive/pull/288

PatrickL reviews the pull request comments

Ulf: I am not quite aligned with the terminology yet
... there is quite a bit of discussion still on the signal node type
... it feels a bit outdated as we have several new node types

PatrickL: completely agree with you but want to capture what is currently represented

Ulf: ok with an intermediate step

PatrickL: we can make incremental changes as easier to digest

Ulf: there is no mention of these new extensions to the VSS data model which we are inheriting from ViWi such as the resource extension

PatrickL: I haven't given that thought yet. it is only there for now as described in the graphics
... an objection to me merging my pull request, it seems sensible to ask

<scribe> … done

<PatrickLue> https://github.com/w3c/automotive/pull/289

UNKNOWN_SPEAKER: next one, wildcard usage over http chapter added
... I confess to not having read that yet, has anyone else had the chance?
... based on the size of the change, I would be comfortable if you provide some background here

Ulf: I think everyone is aware of the wildcard mechanism in VISS, allowing path description to address several nodes
... with the current model for gen2 and wanting to ensure we carry forward desireable features from VISS and ViWi
... for the web socket protocol it will be the same as it was before, for http we need to encapsulate this in the request URL
... wildcards are special/reserved characters in URL according the RFC

<PatrickLue> Discussion from May 2018 around queries: http://www.w3.org/2018/05/29-auto-minutes.html#item01

Ulf: I have a couple ideas and we could try to settle upon one or allow for both
... we can replace * with the corresponding ascii hex value as that is allowed by RFC
... that makes the expression a bit unfriendly to read and thought a bit more about it to try to come up with something more friendly
... we could use a different character than * and chose the ~ as an alternative
... I stated wildcard usage shall be supported, required by conformant server implementations

PatrickL: we had a discussion around this previously, need to find the sweet spot
... what I don't like is addressing and querying combined, they are two distinct things

Ulf: I think they can complement each other, the query mainly to be used for resource type nodes
... there the query mechanism is necessary

PatrickL: to me the example to find all doors that are open, it seems more natural to get all doors where open=true
... addressing something with wildcards is a query for me
... because I am not addressing one object but a series of them
... I think it would be hard to express all with wildcards

Daniel: there is an open issue with VSS regarding the positioning within the tree
... position can be encoded eg right, rear
... we were wondering about that at the end of the path
... having position at the end may facilitate

Ted: querystring may allow for special characters that are otherwise prohibited in server/path and other portions of a URI and would need to confirm
... we can have multiple wildcards at different points in a tree/path which complicates things, having a partial path and then querystring that includes different branch levels would be complicated
... we should come up with an array of possible wildcard examples in VISS and map them to proposed URI solutions

Ulf: I am not so focused on the mechanism but want to ensure we continue to support the feature

<PatrickLue> <service>/car/doors/?open=true

PatrickL: the ViWi style anotation would be as follows

[what i am struggling with are scenarios that would have foo/*/bar/* in VISS]

[after you go qs you can't return to address path in url]

Ulf: as long as we can get the same functionality, I am fine with any mechanism

<PatrickLue> <service>/car/doors/?row=*&side=*&open=true

PatrickL: every level has a certain idea behind it, /car/doors/?row=*&side=*&open=true for example could address Ted's point

Daniel: coming back to VSS, positioning is awkward as I mentioned I will bring forward some ideas
... we need to avoid breaking the tree structure. taking parts out of the tree path and put in query would be a bit off too
... let me work on an idea for next week

PatrickL: based in the discussion let's hold on the pull request

Ulf: absolutely, that is fine

[Agenda bashing for this and next week]

Issues

<PatrickLue> https://github.com/w3c/automotive/issues/287

PatrickL: we have not agreed yet on addressing schema yet to my knowledge
... proposal is we want a URL style addressing converting . to /
... Ulf is already referencing the style we know from VISS and think we should have one addressing style throughout, independent of protocol

<PatrickLue> https://www.w3.org/2018/08/28-auto-minutes.html#item01

Ulf: I would support that

Peter: makes alot of sense

PatrickL: people have until I finish typing in gh to object
... next issue is... usage of wildcards...

[covered with plan to return after hearing idea Daniel is forming]

<PatrickLue> https://github.com/w3c/automotive/issues/282

Ulf: it is not followed in the current specification text, so I would like to kill the idea

agree

<PatrickLue> https://github.com/w3c/automotive/issues/281

PatrickL: the rest are non-gen2 issues
... any brief topics anyone wants to discuss in remaining time?

Ulf: just a shameless plug to encourage people to check out the implementation and consider contributing to it
... servers implemented in JS, uses VISS path for search path responding with number of matches
... it can keep a number of http and web sockets concurrently
... it is progressing, looking for contributors

[adjourned]