See also: IRC log
<scribe> scribenick: ted
<scribe> Scribe: Ted
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
[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://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...
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:
<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
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