<scribe> scribenick: ted
<scribe> Scribe: Ted
<PatrickLue> https://github.com/w3c/automotive/pull/298
PatrickL: I tend to do a series
of smaller commits combined as a larger pull request to explain
each piece
... it is easier for others to follow
... core idea is to have a simplification of the implementation
by reducing the number of tree node types to two
... removing the different style leaf types since in my mind it
makes it easier
Daniel: reasoning for the different types pertain to whether they are writeable for instance
PatrickL: understand the merits
but want us to be able to avoid issues with gen2 access spec if
types changes
... branch type is similar to Ulf's rtype
... I also removed all the different number types as it is
independent on implementation being used
... float has a specific meaning in computer science world but
not always that clear
... at the same time I introduced a default template that
allows for different descriptions and ranges
... another example is date, which is really a string with
formatting distinctions
... I refer to schema quite a bit, expecting each tree to have
a detailed, readable schema
... to have a wide range of views is important. we want to be
able to support multiple transport protocols
... unsure how much people have read through the pull
request
Peter: does this mean you want us
to diverge from VSS or proposing these changes upstream to
it?
... I don't want to split into two data models
... not clear if the complexity is being moved elsewhere. I
would need to have a closer work
PatrickL: it should be compatible
with the current state, completely describeable within gen2
description
... we described what the charter of this WG is. it is to
create a protocol specification that can be used in the vehicle
and that is what I am after
... if GENIVI follows what we are producing, I would be
happy
... what I and my company want is to follow the charter
... last week I was surprised at the enhancements to VSS which
is something I can't do at the moment
Daniel: right now as you say it
is compliant with VISS and earlier VSS
... do you see a benefit with different descriptors?
PatrickL: no
... it combines both views
https://www.w3.org/auto/charter-2018
Ted: I can see how the charter can be interpreted for previous or ongoing VSS
PatrickL: I am trying to bring
core ideas of submission into this pull request
... conversation is stalled on the pull request at present
Daniel: what we are changing in
the current version of VSS is coming from this group
... concerns in the VSS pull requests from Gunnar and Ulf have
not been handled yet
... one could argue from charter perspective
PatrickL: my charter comments
were to explain my confusion about state we are currently
in
... to Ulf and Gunnar's point, it is not progressing to
something I cannot pinpoint
... there are two sides working on something
... I am not getting feedback on the ideas of the pull request
but the direction of it
... the direction is made clear based on description of the
charter
... the intent of the direction is what is being questioned. it
is not meant to pull away from GENIVI side (VSS) but to bring
the core of the VW submission with the state of VSS
... VISS has evolved and being used publicly so understand
starting from that is logical
Ted: my understanding of Ulf's rbranch was to help bridge the divide between VISS and ViWi, agree type for one kind of branch but not the rest is a bit awkward
PatrickL: the idea in the gen2
data model pull request for this additional description for all
branches is a play on Ulf's solution
... to describe all branches in the same manner instead of
having a special type
Ted: sure he would be open to alternative ideas and would like us to tease apart issues with the underlying VSS
PatrickL: it is a great idea to be able to describe branches and should not be restricted to one corner case
https://github.com/GENIVI/vehicle_signal_specification/issues
Ted wondering if rbranch is merged previously, believe it was
Daniel: that was before me
Peter: where are we, considering forking?
Daniel: we want to avoid going so
far away from the original VSS but open to dramatic
changes
... there have been some incremental changes that didn't fit
well due to retaining legacy
... I am open to the discussion
PatrickL: I do not want
documentation in different locations, one doesn't know what to
rely on
Ted: it is common for specs to reference other works, here is is difficult having two moving simultaneously in different organizations even though essentially the same parties
Daniel: both are in flux and can
influence one another, agree we want to reduce confusion
... we would want to keep them together
... I want to understand the problems better before responding
to the pull request
PatrickL: simplification
described at the beginning was with implementation complication
in mind
... I could not come up with another solution
Daniel: by that you mean sensor and data types?
PatrickL: right, everything
becomes a branch and leaf
... after that value description comes into play
... whether a value is changeable
Daniel: access should be out of the data model
PatrickL: I hope the problems I
see are now clearer to the group and prepared to answer any
questions that might arise
... reading Ulf's comment, he cautions against moving away from
VSS in gen2
... should not be a problem if we are moving together
... it is also a question on how we work on this together
... we need a rationale for the moves
... clear we are not going to reach any conclusion so we should
continue by email or on github. sidenote, unavailable for the
next two calls due to travel
Peter: not sure how to
proceed
... if changes should be made to VSS to be condusive
PatrickL: if people agree with the pull request
Peter: we are all in agreement that one model is a good thing
PatrickL: agenda for next week, OCF?
Don: hopefully, will confirm
[adjourned]