PatrickL: room at VW in California for 12 and 13 September looks promising
Ted: workshop at Uber set for start of the week
<PatrickLue> https://github.com/w3c/automotive/pull/303
PatrickL: any comments or alright to merge?
<PatrickLue> https://github.com/w3c/automotive/pull/302
<PatrickLue> Data types
PatrickL: all comments raised in gh should be addressed
Ulf: I think it is fine as such,
question is whether this should be in this spec or VSS
directly
... it logically belongs there
PatrickL: I see data types as central to what a protocol would transport
Gunnar: so these cannot be coded differently on different transports
PatrickL: correct, encodings should be compatible but would not demand same on the wire
Gunnar: idea is to write a set of rules the other documents would follow, eg for Strings there needs to be a max length
Daniel: I would like a concrete
example of how it would look like in practice
... the mapping is not quite clear yet on how it should be
done
... hard to understand out of context
PatrickL: what kind of transport should the example use?
Daniel: last week we had a
discussion about uid and one idea on how to do it
... how to map to description in VSS
PatrickL: isn't that given with all VSS types?
Daniel: main id concept is different from the others. it seems like a good idea
Gunnar: only reason I asked was
because I figured Patrick had a better idea on how things
map
... we want to be sure what is put in the generic pieces work
in practice
... we should move towards concrete practice as that is what
would be implemented in the end
<PatrickLue> https://raw.githack.com/PatrickCQ/w3c-automotive/data-types/spec/Gen2_Core.html
Gunnar: should we write a separate document on how to apply this spec on VSS, any linkage missing?
PatrickL: I don't need such a
document, I have it in mind to say it supports VSS and open to
language behind that
... all the data types copied from VSS are still in there, not
sure what is being asked right now
Gunnar: right, not so much on data types
Daniel: we can discuss at a subsequent pull request
PatrickL: any hesitation on proceeding with this one then?
<PatrickLue> Filter https://github.com/w3c/automotive/pull/295
PatrickL: Daniel, could you elaborate on your comment?
Daniel: related to positioning
discussion, the structure will have positions at end
... given the path relation to VSS important to note the
change
Ulf: agree it is probably a good
idea to wait for VSS to settle
... we have discussed willingness to move away from wildcards
based on this
Gunnar: I like the wildcards but do not understand the alternative fully
Ulf: our goal is to make it easier for URLs
Daniel: I will accept a deadline on positioning piece so we can come back to this
PatrickL: there is little wording
left with wildcards mentioned. Peter brought this up suggesting
we can work on it again
... I'm not sure this could not be more a rule desired from
interface side and not what a data model could offer
... there is nothing about positioning in the filtering
section, parts of tree that can be filtered from interface
perspective
... it is hard for me to describe interface with information
given at present, we can wait another week but do not get the
connection between the two topics
Daniel: it is more about making it clearer
PatrickL: I do not see a direct dependency on the two topics
Gunnar: what rules should be fullfilled by VSS is the same discussion
Daniel: tree would be outdated in the example based on positioning change
PatrickL: agree, example does include positioning but still do not see it as blocking
Daniel: generic filtering makes
sense and fine to proceed but would not want an outdated
example
... we can update the description later or wait another
week
PatrickL: I would still be inclined to accept the pull request and look forward to a new one for updating examples accordingly
Ulf: ok with me
Gunnar: everyone OK that the
query is asking for a particular type of node or would be
specified separately with a rule set to match?
... do you have an example on node types being part of
query?
PatrickL: the tree you have in front of you is too huge to work on as a whole which is why you are asking the service for a specific part, certain path for a region which could be a door or anything...
Ulf: I think this is a good approximation at this point and will move us forward
<PatrickLue> Simple tree elements https://github.com/w3c/automotive/pull/304
PatrickL: I was not able to
create examples for mapping
... tree elements pull everything necessary to create an
interface to VSS universe and there are quite a few things
known from VSS but not everything is copied, this is a
simplification
... should I write up a description of how a simpler version
matches up to VSS or should we evaluate it differently?
Ulf: I think should not go in at all. we had this survey which pointed that the group wants VSS to be the data model we use in all examples in the specification in which case there is no space for this
PatrickL: want it to be possible
to support different transport mechanisms and need a
description of key/value pairs and tree structure
... I tried to do that in the simplest set of rules I could
come up with
Ulf: I still do not see the need for it
Gunnar: main part being discussed in branch types? that what we are disagreeing on
PatrickL: yes
Daniel: the bare minimum would be
the mapping
... name and id don't map right now, it goes away from the
spec. to get the combination and if it should be automatically
mapped is not clear yet
PatrickL: fair and understood and
not something I can do with the current VSS
... I put extensive comments on commits to follow the train of
though, I get need for seeing the mapping
... do people see the description of the methods with path and
filter and within filtering what object would be as something
that can be described without simplification of the tree
elements
... I see a gap there and would appreciate the chapter 4 data
model in the right amount of information so we can solve this
point
Gunnar: maybe use screen sharing to focus on same wording changes
Daniel: that would be helpful
PatrickL: I appreciate we want to be clearer about how it maps to VSS to be easier to understand
Ulf: think it is clear we want to use VSS in spec including examples and as such not use an abstract description
PatrickL: simplification is
always an abstraction and would like to see that to reduce
overhead in implementing
... examples being used here are the same as in the initial
version of the document
Gunnar: why not simplify in VSS as well?
Daniel: I don't see a
simplification in the desciption, we can discuss branch types
and see where simplification is needed
... if there is an example in the mapping in how you envision
that we can review
PatrickL: I can work on having
example mapping available to VSS
... any other questions for this pull request people want
addressed?
... any changes to tree in GENIVI being discussed such as
positioning or can we go off initial description Ulf provided
for this document?
Daniel: positioning and types
simplification we can talk about, if we want to understand why
we have the node types and can send a link to that
discussion
... we can see if there is an action point on VSS
PatrickL: would appreciate the
discussion on leafs being made available
... anything else for today?
Gunnar: do we have time to address the other pull requests?
PatrickL: the other Gen2 items are issues being discussed, wildcard usage and wake events
<PatrickLue> https://github.com/w3c/automotive/issues/300
PatrickL: they are not active discussions
<PatrickLue> Wake events and heartbeat
<PatrickLue> speaking about this commit https://github.com/w3c/automotive/issues/300#issuecomment-469477732
Gunnar: I am not so interested in this topic
PatrickL: I posted my opinion earlier and don't see it
Ulf: I will close wildcard issue
Ted: I will close wake issue
Daniel: https://github.com/GENIVI/vehicle_signal_specification/issues/79