PatrickL: Genivi AMM is 14-16 May in Munich
Magnus: I think I will be there anyway
Guru: I will be attending
Daniel: looks good for me
Ted: as we may want to hold a transportation data workshop as mentioned in member-automotive mail in June in California, I was wondering if we might want to have our face to face there
PatrickL: Wonsuk raised this as
he needs to start scheduling his travel
... we should go with absolute, less visa concerns for
some
... we had some collisions last year and may want to be careful
scheduling to avoid conflicts with AMM
Magnus: we have had that problem before
Ulf: how about the first and second day as that is usually less critical?
PatrickL: I haven't seen the agenda yet to be able to inform an opinion on which days
Magnus: earlier is often more committees, later the technical groups
Guru: I think a Monday/Tuesday would be fine
PatrickL: Proposed 13 and 14 May,
2019
... I will send an email to the list to see if there are
concerns and encourage people to respond with their
availability
Guru: we might miss out on Gunnar's time since he may be busy
Ted: we should perhaps ping Gunnar and Karin to ensure they can accomodate us
PatrickL: plenty of alternatives abound in Munich should they not be able to
https://github.com/GENIVI/vehicle_signal_specification/issues/81
Daniel: last week we discussed
about REST API and how we can sort by various parameters
... the problem is change of positioning modeling in VSS is not
new
... we discussed at the last face to face. Benjamin drafted
this issue
... three points: why to consider a change here. not so good if
position is encoded in the path which is identifier to the
leaf
... in VSSo the positioning is more an attribute and not part
of the identifier
... there can be zoning complications too. thinking about
improving adoption of the specification prompts modifying
now
... Benjamin proposed putting zone at the end, for time
pressure example you can give row
... I propose to have a new field in a branch, called position
and can then look at position attributes which can be left,
right, row, index etc
... we can use enumeration or an identifier. they can be fixed
and defined or dynamic
... you can generate the tree after using the tooling we
have
... it can check for all positions in the path and move them to
the end
... I think this would solve some of the problems
Ulf: this makes sense. I tried to
visualize the resulting tree. we will reduce redundancy in
vspec which is a good idea
... in the last part where you have all the rows with the
paths, I could not see what that would look like in the
tree
... typically the leaf nodes are what carry the data, here the
pressure node would carry it
... positioning not nodes in the tree?
Daniel: tire pressure, row 1, left would be a specific node. if you omit eg left or right for a given request you would get both for designated row
Ulf: please produce a visual representation as that would help
PatrickL: it is essentially
doubling the branches on the tree for mirrorable nodes eg
across axles
... is that a fair summary?
Daniel: it puts the positioning
at the end, leaf nodes. think of multiple leaves at end of
branch
... I would rather see it as an attribute to avoid
mistakes
... you can address a single leaf or provide path including
positioning
Benjamin: the best example you
have in VSS is seats. you should be scared as they are
currently hard coded
... it is really hard to review vspec as there is unneccessary
redundancy
... you want to get a pressure leaf with the attribute
position
Daniel: you can use positioning
id for querying or explicitly in the path
... I can come back next week as a branch commit is made and
resulting resources
Tim: JSON has addressed this by
embedded the accessors at the level at which they apply
... it makes clear on what is the axle and what is the wheel.
it makes sense as a developer
Daniel: that looks good for the
JSON part
... we could do addressing like this for JSON. it would not
stop you from getting to the pressure
Ted: there are various issues
coming up from the data task force's contract discussions. some
may influence VSS or v2 of VISS and we will like to bring
specific ones here to the working group for further
discussion
... before raising issue on github, for some we will try to
introduce on call or in mail thread
... we previously mentioned desire to have degree of precision for
given data points and Daniel indicated that would make sense in
VSS
... another we are discussing is the business cases for heartbeat
monitoring or wake events, if/when v2 will be available while the
car is off
... we understand and affirmed by Gunnar that justification needs
to be strong and OEM will vary on whether they would allow it
Glenn: there were a couple cases
that came up, one was when there were a number of major wild
fires
... using a heartbeat we were able to locate vehicles within
this cordoned off area
... another would be for courier companies
Ted elaborates on courier towing use case
Glenn: there are two general
cases, one for accuracy of the underlying sensor
... in some cases the data changes rapidly before stabilizing.
we may want to focus on the changes and not for more static
values
Ted: does this make sense to raise as an issue for inclusion in v2?
Ulf: agree it is an issue to
discuss but unsure how to introduce it within the specification
and effects it would have
... power consumption is indeed an important issue and you need
to be very careful in this context
... should this API be able to control the wake-up? configure
it, not option for client app to decide
Ted to raise issue in Github
Daniel: I have a colleague who gave a presentation and his thoughts on GraphQL
PatrickL: in remaining time, any open issues to take up?
<PatrickLue> https://github.com/w3c/automotive/labels/gen2
PatrickL: we have four open issues, one associated with a pull request that would take too much
<PatrickLue> Unsubscribe All Feature: https://github.com/w3c/automotive/issues/291
PatrickL: given remaining time
let's go into unsubscribe all
... Ulf described a -1 subscription id that would result that
client unsubscribing from all subscriptions
... I am challenging the group on this concept as I am unclear
on the benefit
... unsubscribe should be handled with the same degree as care
as the subscriptions initially
Ulf: I support you there
PatrickL: no fair, I wanted to argue...
Gunnar: any other way to get a reset state?
PatrickL: when created interface is destroyed by client all subscriptions would be closed
Gunnar: action to be taken then by client
PatrickL: I see the server implementation doing the garbage collection of subscriptions when the client no longer exists
Gunnar: mechanism to recognize?
PatrickL: timeout
Gunnar: I agree unsub all would not be a normal operation but we may want a reset
PatrickL: I see it at protocol
specific and not part of our defined interface
... any objections?
Gunnar: not as long as the meta question stays open
PatrickL: yes, for each protocol there needs to be proper handling
Ulf: it could be described in our transport document for each protocol. we discuss lifetime of a session
Gunnar: works for me
PatrickL: encourage all to look at open issues
[adjourned]