22:54:51 RRSAgent has joined #auto 22:54:51 logging to http://www.w3.org/2017/03/13-auto-irc 22:54:53 RRSAgent, make logs public 22:54:53 Zakim has joined #auto 22:54:55 Zakim, this will be 22:54:55 I don't understand 'this will be', trackbot 22:54:56 Meeting: Automotive Working Group Teleconference 22:54:56 Date: 13 March 2017 22:57:43 rstreif has joined #auto 22:59:42 hira has joined #auto 22:59:57 urata_access has joined #auto 23:02:24 junichi-hashimoto has joined #auto 23:02:46 AdamC has joined #auto 23:05:54 Present+ Junichi, Hira, Mike, Peter, Rudi, Ted, Adam, Songli 23:06:00 Chair: Rudi 23:06:02 scribenick: ted 23:06:06 Scribe: Ted 23:06:49 mike has joined #auto 23:06:58 Agenda: https://lists.w3.org/Archives/Member/member-automotive/2017Mar/0027.html 23:07:13 wonsuk has joined #auto 23:08:01 agenda+ Call the Meeting to Order / Roll Call (5 min) 23:08:01 agenda+ General feedback on the status of the specification (15 min) 23:08:01 agenda+ Work through issues reported on GitHub tracker (90 min) 23:08:01 agenda+ Break (15 min) 23:08:04 agenda+ Work through issues reported on GitHub tracker (90 min) 23:08:07 agenda+ CR Preparation Process (15 min) 23:08:10 agenda+ Action Items (10 min) 23:08:55 Present+ Urata, Wonsuk 23:09:34 zakim, next agendum 23:09:34 agendum 1. "Call the Meeting to Order / Roll Call (5 min)" taken up [from ted] 23:10:36 Rudi: I know many of you have been implementing, working on a test framework. a few issues to review and address on github 23:11:27 … reaching conclusion and commenting directly in github or perhaps even correct the spec 23:11:41 [review of agenda] 23:12:37 Peter: I cannot stay long but wanted to confirm we are implementing 23:12:42 q+ 23:13:19 Rudi: understood as this time is not convenient to those in EU 23:14:05 … we are going to rotate these calls and try to distribute the discomfort across timezones 23:14:32 Adam: likewise I probably will not attend the extended session 23:15:50 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 23:16:14 Peter: it is progressing well and finding the spec easy to follow 23:16:32 … we have all the pieces together and working on auth manager part now 23:17:12 … there are some issues I filed of minor details we found. we have further to go including testing phase, so far it works fine 23:18:44 … we should have a report we can share, the source code itself is open 23:20:23 Rudi: Songli, since we are on that topic perhaps you can share as well 23:20:45 Songli: we also should be able to open source as well 23:21:39 -> https://www.w3.org/2015/Process-20150901/#candidate-rec CR requirements 23:22:19 -> https://www.w3.org/2015/Process-20150901/#implementation-experience Implementation reports 23:23:20 [reviewing github issues] 23:23:53 -> https://github.com/w3c/automotive/issues/145 Undefined Wildcard behaviour for getVSS request (Issue #145) 23:24:23 Adam: do we need to extend the description? 23:25:18 Peter: I am proxy for this report 23:25:45 … I think he was wondering why signal.cabin wouldn't return the same things as signal.cabin.* 23:26:24 Rudi: that is certainly possible 23:26:46 [discussion of other use cases with * elsewhere in path] 23:28:35 Urata: should I expect the tree returned from cabin or underlying components, what is the root element? 23:29:06 … the tree itself should start with signal 23:29:39 Rudi: that deserves clarification and that it should start with signal as the top level element 23:30:08 s/and that it should/and agree that it should/ 23:33:25 Present+ Paul 23:36:16 Adam: look at the example in section 8 of the flattened tree 23:41:41 Junichi: I would expect a list back from wildcard 23:41:58 … getvss is about getting back the tree, * doesn't make sense 23:42:30 Rudi: we don't have * in 23:42:58 … you can specify a path all the way down to a leaf 23:44:56 Adam: you may want to get signals below a common path or end point. a hybrid engine can have combustion and electric rpm 23:56:45 question: does * only expand to next level down or anywhere in the tree? 23:58:23 [arguments for both sides so might be worth distinct and separate options, rewording in draft gh issue response being reviewed/refined] 00:02:31 Urata: a ** isn't a commonly used syntax as far as I am familiar 00:02:58 Ted: me neither but Rudi is right from filesystem expansion there isn't that kind of expansion 00:03:01 https://www.w3.org/TR/xpath/ 00:04:05 https://en.wikipedia.org/wiki/XPath#Abbreviated_syntax 00:06:07 kaz has joined #auto 00:06:57 Urata: maybe we want to make wildcard optional by implementers. some might want to only implement one *, one level down 00:18:02 Ted: I am concerned about optional implementation as developers who used it on one platform would not be able to on another 00:18:54 … that would break interoperability 00:18:55 … 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 00:19:13 Rudi reviews draft response 00:19:58 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 00:21:28 Rudi: we could stick with no wildcards, you have to know the parent node you want subtree of 00:21:36 Adam: that is how the current spec reads 00:22:32 [developer will need to know tree and be explicit on multiple paths] 00:25:53 -> https://github.com/w3c/automotive/issues/145#issuecomment-286281787 The getVSS request does not support wildcards... 00:26:21 -> https://github.com/w3c/automotive/issues/144 Filter behaviour unclear 00:28:38 Peter: you can have a response that you are out of range and that is confusing when you explicitly set a range 00:28:55 Adam: the use case is for when you want to know something has left the range you were watching 00:34:10 Peter points out this is a rehash of a previous discussion 00:35:59 Adam: the client app can request what they want explicitly as Ted said if they want to know when it leaves a range 00:37:38 … a connection could timeout or be closed as well 00:45:12 -> https://github.com/w3c/automotive/issues/143 For filter "range", the wording "above" and "below" is misleading 00:46:48 [resolved, keep as is] 00:48:01 -> https://github.com/w3c/automotive/issues/142 When using a wild card ( * ) as part of a path it is unclear how to specify each corresponding value 00:48:43 [draft example clarification in gh comment] 00:49:23 -> https://github.com/w3c/automotive/issues/141 Subscribe repsonse inconsistent (Issue 141) 00:51:46 [resolved in comments and merged with 138] 00:52:25 -> https://github.com/w3c/automotive/issues/140 Question about Authorize() detail #140 00:52:50 Junichi: we should make it explicit it is not mandatory 00:52:56 Urata: I feel the same way 00:54:12 … we should include additional information such as signal path being requested 00:55:06 … I would like to have some things we define as MAY include 00:55:16 Rudi: agree we should reword 00:57:39 yingying_ has joined #auto 01:07:28 -> https://github.com/w3c/automotive/issues/136 Consider adding filtering to Set e.g. to set a subset of doors so that isLocked=true #136 01:08:01 Junichi: I would prefer requiring developer to be explicit 01:08:14 wonsuk has joined #auto 01:08:14 Rudi: locking all doors is a common use case 01:10:36 Urata: I would want to hear more about Kevin's concern before agreeing to a wildcard syntax 01:25:37 Hi Ted-san, I'd like to know list of Action Items to be solved before entering to CR phase. Could you clarify this? 01:26:17 what is needed to reach CR is on the agenda for the call 01:26:39 earlier I provided this link: 01:26:49 -> https://www.w3.org/2015/Process-20150901/#candidate-rec CR requirements 01:26:49 01:26:49 01:29:01 Thanks! In our case, these item must be satisfied by when? end of March? 01:29:39 we are potentially going to have external issues raised. those need to be addressed to leave CR stage 01:30:09 to leave CR we have to say we have responded to all substantive issues raised 01:32:06 OK. That is condition to leave CR stage. Then how about the conditions to enter to CR stage? 01:32:38 entering CR is not as strict. we can have issues still, they need to be well defined and more we can solve the better 01:32:55 see https://www.w3.org/2015/Process-20150901/#candidate-rec 01:33:06 it does not cite we need to have all issues addressed 01:33:33 I got it. Then even if we don't solve any more of github issues, we can enter into CR stage, right? 01:33:57 the problem is though CR prompts outside review. if we have lots of issues without solutions we risk people wasting their time 01:43:36 [discussion of CR requirements] 01:45:17 https://www.w3.org/2015/Process-20150901/#wide-review 01:47:19 https://www.w3.org/2015/Process-20150901/#transition-reqs 01:50:28 https://www.w3.org/2015/Process-20150901/#candidate-rec 01:54:53 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 01:56:31 must record the group's decision to request advancement. [Chair - Rudi] 01:56:31 must obtain Director approval. [Part of publication requst - Ted + Chair] 01:57:20 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] 01:58:42 must formally address all issues raised about the document since the previous maturity level. [doing now. addressed but not necessarily] 01:59:20 must provide public documentation of any Formal Objections. [Chairs and Ted, if we receive any] 01:59:44 that list was from https://www.w3.org/2015/Process-20150901/#transition-reqs 02:00:28 should provide public documentation of changes that are not substantive. [include in changes report, can be concise and point to github] 02:01:27 should report which, if any, of the Working Group's requirements for this document have changed since the previous step. [not applicable] 02:01:42 should report any changes in dependencies with other groups. [no changes] 02:02:18 should provide information about implementations known to the Working Group. [compile from Peter, Songli, Urata, others] 02:02:35 https://www.w3.org/2015/Process-20150901/#candidate-rec 02:03:09 preparing document for publication [Ted] 02:03:17 (not on list but needed step) 02:04:02 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] 02:04:27 must document changes to dependencies during the development of the specification, [not applicable] 02:04:58 must document how adequate implementation experience will be demonstrated, [same - Peter and other listed before] 02:05:34 (during CR we need to work on implementation reports. to enter CR we need to say how we will report on implementation] 02:06:29 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] 02:08:05 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 ] 02:08:16 https://www.w3.org/2015/Process-20150901/#wide-review 02:08:26 https://github.com/w3c/automotive/issues/123 02:10:58 https://github.com/w3c/automotive/issues/124 02:11:01 https://github.com/w3c/automotive/issues/125 02:11:03 https://github.com/w3c/automotive/issues/126 02:12:51 https://www.w3.org/2017/02/06-auto-minutes.html 02:13:36 POST /signal/body/door/lock?all 02:14:53 in viwi you can use the different leaf node elements contents in a querystring 02:15:18 Kevin found being able to get and set in a similar manner in viss as useful 02:15:52 https://github.com/w3c/automotive/issues/135 and https://github.com/w3c/automotive/issues/136 (earlier) 02:16:07 Urata: it is kind of late to introduce such a change 02:16:24 … I want to hear Kevin's thinking again 02:16:26 Junichi: I agree 02:17:04 s|https://www.w3.org/2017/02/06-auto-minutes.html|-> https://www.w3.org/2017/02/06-auto-minutes.html 2G minutes on 6 February| 02:17:57 -> https://github.com/w3c/automotive/issues/132 What fomat of json should be returned by getVSS()? #132 02:18:21 Urata: my questioned was answered and example is clear in spec now 02:18:39 … the conversation went off on a tangent after 02:19:41 Rudi: yes about a visibility flag now 02:20:01 Urata: access control is discussed in 132 02:20:21 Rudi: it is visibility of signals 02:20:43 … Adam suggested adding a visibility flag where you can say if a signal is visible or not 02:20:58 … my argument is there is no need to tell an application what they are not allowed to see 02:21:20 … one might want to supress in getVSS 02:24:23 Urata: getVSS could return everything and if client tries to read a specific item it fails 02:25:35 … do you think it is better to include access control in getVSS? 02:26:01 Rudi: I would prefer to keep it simple and have getVSS return what you are given access to 02:26:55 Junichi: we should expose all visible items. implementer could choose to hide and not return signals based on tokens 02:27:02 … leave to implementer 02:27:42 Rudi: alright 02:29:52 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 02:30:26 … they may have write but no read access. they will need to know to try and handle possibility they will be declined 02:34:04 -> https://github.com/w3c/automotive/issues/99 Using JSON Schema for instead of Web IDL #99 02:36:34 [resolved in issue comments, pending json schema change] 02:36:45 -> https://github.com/w3c/automotive/issues/91 Vehicle Signal Server Spec Actions #91 02:36:53 Hira: this is related to VIAS 02:36:56 wonsuk has joined #auto 02:48:08 Housecleaning of old issues 02:48:09 agenda? 02:50:59 discussion of next meeting tomorrow, tentatively on VIAS 02:51:43 Ted: we should probably figure out in the WG how to handle this going forward with Powell leaving 02:52:01 Rudi: we should probably skip until we resolve 02:52:18 s/skip/postpone and reschedule/ 02:53:36 … and send an email to the WG to see if someone is interested in stepping up 02:54:09 Junichi: perhaps we can cover VIAS briefly during testing call 02:54:14 Rudi: yes since it is related 02:59:30 next meeting Thursday on Testing. 11GMT, 13CET, 20JST, 4PST, 7EST 02:59:32 I have made the request to generate http://www.w3.org/2017/03/13-auto-minutes.html ted 04:02:23 kaz has joined #auto 05:01:18 kaz_ has joined #auto 05:28:19 yingying has joined #auto 05:40:15 yingying_ has joined #auto 06:13:47 yychen__ has joined #auto 06:17:35 yingying_ has joined #auto 06:39:35 yingying has joined #auto 07:33:47 kaz_ has joined #auto