VSS doc pull request for comments
Daniel: I added a bit of
introduction and explanation, using the wording we settled on
before the Summer break
... the earlier readme grew and became too complicated so
restructured it and want to get input
... please provide feedback on the pull request
Ted: agree with moving away from README and tools should be separate but maybe keep the other chapters on one doc
Daniel: under personal repo for now but will move to the main one after review
Ulf: looks great to me and agree the previous grew to point of confusion and support this
Rudi: haven't had a chance to look in detail but happy you did this
<PatrickLue> https://www.w3.org/Submission/viwi-protocol/
earlier ViWi submission including specific services
PatrickL: as promised we got the
internal version ready for public consumption and wanted to go
over some of the changes
... bunch of housecleaning, we extended the formats, updated
coordinate handling, paging if you get a larger dataset
... we are closer to http spec
... paging we looked at extensively
... we introduced something called complex types. it has a
service resource element structure which can be a tree like
structure itself
... we worked on the security model including tokens
Ted: possible to get a changelog?
PatrickL: lots of small commits is the problem
Ted: I will include a htmldiff in minutes https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FSubmission%2F2016%2FSUBM-viwi-protocol-20161213%2F&doc2=https%3A%2F%2Fwww.w3.org%2FSubmission%2F2019%2FSUBM-viwi-protocol-20190718%2F
PatrickL: for authentication
there is more details on how we are handling that. it is user
centric
... in short it is quite similar to oauth. you have an entity
that can grant tokens JWT
... we did a few fixes for CORS handling and wanted to stick
with as many HTTP features as possible
... earlier spec section on signatures for authentication
tokens was harder to follow
... we came up with a version mechanism for a service, for
example you could support multiple clients and opt when to
deprecate older
... we communicate that via content type
Ted: can you elaborate on the complex type some more?
PatrickL: instead of just a
string you can send a struct or object
... struct can be built out of the same elements that a
resource is
... allows for creating a tree more or less
Ted: in addition to these changes perhaps experiences based on experiences from production vehicles
PatrickL: all these feature
changes are influenced by our experiences and developer
feedback
... we extended datetime format instead of using unix
timestamp
... paging needed to be reworked
... authentication influenced by need to support mobile
devices
... versioning came from our endeavors to roll out new versions
and not alienate existing clients
... we did not want to have multiple independent servers
running for the different versions concurrently
... the changes came mostly from our core customer group
Ted: any AGL influences or they just implement it?
PatrickL: no, they just
implemented the earlier 1.6 version without our knowledge and
only more recently started coordinating with them
... we have alot of developers and using this throughout
various units
... some of the more embedded developers are adverse to a
different protocol
Ted: those former embedded engineers or current being encouraged to use ViWi instead of more direct (vehicle specific) means
PatrickL: latter, they don't like
ascii based protocols
... we have a few changes in mind for a November release but
not substantive more for increasing understandability
Gunnar: I read through the
specification but not side by side with the old one
... this is tweaks as described but very much similar. unsure
which are the major changes
PatrickL: multiple version
support and authentication
... it is an evolution not overhaul
Gunnar: for the work we've done not much is changing but to use the best out of ViWi and VISS for Gen2
Ted: actually there has been some
discussions anew about trying to leverage ViWi more for Gen2
... our momentum and progress on Gen2 is slow and no clear
indication any OEM will implement yet
... this group has been clear in their commitment to VSS/VSSo
... AGL also implemented ViWi
... if we can figure out a way to accommodate VSS within ViWi and
perhaps improve subscriptions via sockets and other lessons from
VISS/Gen2 then combined with efforts to get other standards bodies
to adopt VSS we have a better strategy for widespread adoption
Gunnar: tree level still an issue?
PatrickL: the complex types might allow a deeper tree
Gunnar: does that show up in the URL or the JSON payload?
PatrickL: JSON
Gunnar: how much have you been working on ViWi and how much Gen2?
PatrickL: both and there has been
influences. we feel it better to be broad than deep in data
description
... we wanted to keep depth limited as such
Gunnar: tree could influence the path
Ted: please correct me if I have
this wrong
... JLR implemented VISS in IVI, using ViWi for applications
interacting indirectly via cloud
... Volvo implementing VISS on TSU but not planning to expose to
head unit
... BMW more interested in seeing VSS adopted than implementing
Gen2/ViWi/VISS at this point
... VW clearly using ViWi and Patrick would need to persuade VW to
implement a second, parallel Gen2 service and would likely need to
demonstrate wide support
Daniel: we do care about the
protocol but the data model itself is more important, first
priority and secondary is protocol
... taxonomy is more important to me. transport and protocol
will be different for different use cases
... complex type, ok we can discuss
... what I am missing is an example on how to use VSS in this
context
... depth and structs might be sub-optimal
... want to avoid to go back to the beginning of the debate but
would like to see this with VSS
Peter: correct that we have not
made commitment to Gen2 and what we want to see is wider
adoption, we see VSS (data model) as the most important with
the ontology
... we are interested in subscription as we do with VISS
presently and want to see how to do that in ViWi
Gunnar: it should be fairly clear
that we want to see a REST interface to VSS data model
... and makes sense to start with the data model. we expect W3C
standard to be building block therein
<PatrickLue> https://raw.githack.com/w3c/automotive/gh-pages/charter-2018.html
PatrickL reviews the charter
Ted: next step?
Daniel: for me the first thing is
to define that graph but also to be able to link them
together
... we need to define this graph and see what it looks like
PatrickL: I'm not saying this
current version into the group
... not sure the order you propose is the right one. this was
not designed from VSS in mind
Gunnar: are there more property descriptions than we can see in the submission?
PatrickL: there can be as many
properties as you would like, it is open in that manner
... you can describe the world as detailed as you like
Gunnar: there is no public descriptions of data models
PatrickL: they were made available as part of the initial submission
<PatrickLue> Media: https://www.w3.org/Submission/2016/SUBM-viwi-service-media-20161213/
<PatrickLue> Vehicle Data: https://www.w3.org/Submission/2016/SUBM-viwi-service-car-20161213/
<PatrickLue> Mixer: https://www.w3.org/Submission/2016/SUBM-viwi-service-mixer-20161213/
PatrickL: we think in
microservices, there are multiple domains
... I will work on getting a VSS representation in ViWi
Daniel: please feel free to ping me
PatrickL: the current vehicle.vspec what I should be looking at?
Daniel: position reorg is pending but will send link to that issue
Rudi: interesting that we are
revisiting this discussion
... VISS is not completely be incompatible with RSI/ViWi
... there should be a way to bring them together
Gunnar: we will wait for Patrick's proposal