Automotive Working Group VISS review for CR

<scribe> scribenick: ted

<scribe> Scribe: Ted

Call the Meeting to Order / Roll Call (5 min)

Rudi: I know many of you have been implementing, working on a test framework. a few issues to review and address on github
... reaching conclusion and commenting directly in github or perhaps even correct the spec

[review of agenda]

Peter: I cannot stay long but wanted to confirm we are implementing

Rudi: understood as this time is not convenient to those in EU
... we are going to rotate these calls and try to distribute the discomfort across timezones

Adam: likewise I probably will not attend the extended session

Ted: Peter, in the minutes for going to CR requirements will be a pointer for implementation reports. it would be great to get one from Melco

Peter: it is progressing well and finding the spec easy to follow
... we have all the pieces together and working on auth manager part now
... there are some issues I filed of minor details we found. we have further to go including testing phase, so far it works fine
... we should have a report we can share, the source code itself is open

Rudi: Songli, since we are on that topic perhaps you can share as well

Songli: we also should be able to open source as well

CR requirements

Implementation reports

[reviewing github issues]

Undefined Wildcard behaviour for getVSS request (Issue #145)

Adam: do we need to extend the description?

Peter: I am proxy for this report
... I think he was wondering why signal.cabin wouldn't return the same things as signal.cabin.*

Rudi: that is certainly possible

[discussion of other use cases with * elsewhere in path]

Urata: should I expect the tree returned from cabin or underlying components, what is the root element?
... the tree itself should start with signal

Rudi: that deserves clarification and agree that it should start with signal as the top level element

Adam: look at the example in section 8 of the flattened tree

Junichi: I would expect a list back from wildcard
... getvss is about getting back the tree, * doesn't make sense

Rudi: we don't have * in
... you can specify a path all the way down to a leaf

Adam: you may want to get signals below a common path or end point. a hybrid engine can have combustion and electric rpm

question: does * only expand to next level down or anywhere in the tree?

[arguments for both sides so might be worth distinct and separate options, rewording in draft gh issue response being reviewed/refined]

Urata: a ** isn't a commonly used syntax as far as I am familiar

Ted: me neither but Rudi is right from filesystem expansion there isn't that kind of expansion

https://www.w3.org/TR/xpath/

https://en.wikipedia.org/wiki/XPath#Abbreviated_syntax

Urata: maybe we want to make wildcard optional by implementers. some might want to only implement one *, one level down

Ted: I am concerned about optional implementation as developers who used it on one platform would not be able to on another
... that would break interoperability
... if it would be costly to implement any depth level then we should limit it to one expansion, similar to how wildcard work in filesystem as Rudi noted

Rudi reviews draft response

Urata: this is a heavy issue to try to resolve at this depth, we have been on this one for quite a bit of time and might be better to continue conversation in github

Rudi: we could stick with no wildcards, you have to know the parent node you want subtree of

Adam: that is how the current spec reads

[developer will need to know tree and be explicit on multiple paths]

The getVSS request does not support wildcards...

Filter behaviour unclear

Peter: you can have a response that you are out of range and that is confusing when you explicitly set a range

Adam: the use case is for when you want to know something has left the range you were watching

Peter points out this is a rehash of a previous discussion

Adam: the client app can request what they want explicitly as Ted said if they want to know when it leaves a range
... a connection could timeout or be closed as well

For filter "range", the wording "above" and "below" is misleading

[resolved, keep as is]

When using a wild card ( * ) as part of a path it is unclear how to specify each corresponding value

[draft example clarification in gh comment]

Subscribe repsonse inconsistent (Issue 141)

[resolved in comments and merged with 138]

Question about Authorize() detail #140

Junichi: we should make it explicit it is not mandatory

Urata: I feel the same way
... we should include additional information such as signal path being requested
... I would like to have some things we define as MAY include

Rudi: agree we should reword

Consider adding filtering to Set e.g. to set a subset of doors so that isLocked=true #136

Junichi: I would prefer requiring developer to be explicit

Rudi: locking all doors is a common use case

Urata: I would want to hear more about Kevin's concern before agreeing to a wildcard syntax

<urata_access> Hi Ted-san, I'd like to know list of Action Items to be solved before entering to CR phase. Could you clarify this?

what is needed to reach CR is on the agenda for the call

earlier I provided this link:

CR requirements

<urata_access> Thanks! In our case, these item must be satisfied by when? end of March?

we are potentially going to have external issues raised. those need to be addressed to leave CR stage

to leave CR we have to say we have responded to all substantive issues raised

<urata_access> OK. That is condition to leave CR stage. Then how about the conditions to enter to CR stage?

entering CR is not as strict. we can have issues still, they need to be well defined and more we can solve the better

see https://www.w3.org/2015/Process-20150901/#candidate-rec

it does not cite we need to have all issues addressed

<urata_access> I got it. Then even if we don't solve any more of github issues, we can enter into CR stage, right?

the problem is though CR prompts outside review. if we have lots of issues without solutions we risk people wasting their time

[discussion of CR requirements]

https://www.w3.org/2015/Process-20150901/#wide-review

https://www.w3.org/2015/Process-20150901/#transition-reqs

https://www.w3.org/2015/Process-20150901/#candidate-rec

<hira> In summary, we need to decide the criteria to enter CR phase in our group. 1. to solve the major concerns on FPWD 2. to provide the Implementation Test Plan including testing architecture of Test Suite

must record the group's decision to request advancement. [Chair - Rudi]

must obtain Director approval. [Part of publication requst - Ted + Chair]

must provide public documentation of all substantive changes to the technical report since the previous publication. [Editors best suited to review pull requests and provide summary of diffs/changes]

must formally address all issues raised about the document since the previous maturity level. [doing now. addressed but not necessarily]

must provide public documentation of any Formal Objections. [Chairs and Ted, if we receive any]

that list was from https://www.w3.org/2015/Process-20150901/#transition-reqs

should provide public documentation of changes that are not substantive. [include in changes report, can be concise and point to github]

should report which, if any, of the Working Group's requirements for this document have changed since the previous step. [not applicable]

should report any changes in dependencies with other groups. [no changes]

should provide information about implementations known to the Working Group. [compile from Peter, Songli, Urata, others]

https://www.w3.org/2015/Process-20150901/#candidate-rec

preparing document for publication [Ted]

(not on list but needed step)

must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred, [Chairs include citation of charter and assertion that requirements are met in publication request]

must document changes to dependencies during the development of the specification, [not applicable]

must document how adequate implementation experience will be demonstrated, [same - Peter and other listed before]

(during CR we need to work on implementation reports. to enter CR we need to say how we will report on implementation]

must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents, [Chair as part of publication request - Ted will provide a template for this and the other pieces to be part of request]

must show that the specification has received wide review, [Chair send a heads up that we intend to go into CR in April to public-review-announce@w3.org ]

https://www.w3.org/2015/Process-20150901/#wide-review

<urata_access> https://github.com/w3c/automotive/issues/123

<urata_access> https://github.com/w3c/automotive/issues/124

<urata_access> https://github.com/w3c/automotive/issues/125

<urata_access> https://github.com/w3c/automotive/issues/126

2G minutes on 6 February

POST /signal/body/door/lock?all

in viwi you can use the different leaf node elements contents in a querystring

Kevin found being able to get and set in a similar manner in viss as useful

https://github.com/w3c/automotive/issues/135 and https://github.com/w3c/automotive/issues/136 (earlier)

Urata: it is kind of late to introduce such a change
... I want to hear Kevin's thinking again

Junichi: I agree

What fomat of json should be returned by getVSS()? #132

Urata: my questioned was answered and example is clear in spec now
... the conversation went off on a tangent after

Rudi: yes about a visibility flag now

Urata: access control is discussed in 132

Rudi: it is visibility of signals
... Adam suggested adding a visibility flag where you can say if a signal is visible or not
... my argument is there is no need to tell an application what they are not allowed to see
... one might want to supress in getVSS

Urata: getVSS could return everything and if client tries to read a specific item it fails
... do you think it is better to include access control in getVSS?

Rudi: I would prefer to keep it simple and have getVSS return what you are given access to

Junichi: we should expose all visible items. implementer could choose to hide and not return signals based on tokens
... leave to implementer

Rudi: alright

Ted: problem with that is developer will only know what they can read not write. they should know what is reasonable for them to expect to write/do eg lock doors
... they may have write but no read access. they will need to know to try and handle possibility they will be declined

Using JSON Schema for instead of Web IDL #99

[resolved in issue comments, pending json schema change]

Vehicle Signal Server Spec Actions #91

Hira: this is related to VIAS

Housecleaning of old issues

discussion of next meeting tomorrow, tentatively on VIAS

Ted: we should probably figure out in the WG how to handle this going forward with Powell leaving

Rudi: we should probably postpone and reschedule until we resolve
... and send an email to the WG to see if someone is interested in stepping up

Junichi: perhaps we can cover VIAS briefly during testing call

Rudi: yes since it is related

next meeting Thursday on Testing. 11GMT, 13CET, 20JST, 4PST, 7EST