- From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- Date: Wed, 21 Aug 2019 11:25:18 +0200
- To: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Cc: "Winzell, Peter" <peter.winzell@volvocars.com>, "ted@w3.org" <ted@w3.org>, Peter Winzell <peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org>
- Message-ID: <CAHfMbK_VgnrXiGtteJ9o2qYTO6o4BCy5k6YJT0m-veDy-rL3Bg@mail.gmail.com>
Rudi, I must give you credit for directly coming up with a technically viable alternative. However, I am not sure it is equally practically viable. A few examples on the top of my head: - when problems occur, the trouble shooting gets considerably more complex. - more complex VSS branch structures (depth more than 3, with sub-branches) will have to be represented as multiple 3-level VIWI branches. - As SHA256 is one-way, decoding a SHA256 encoded expression back to VSS may involve large tables to be searched. - Addressing all leaf nodes below Row4, Pos1 (Vehicle.Cabin.Seat.Row4.Pos1.*) will break the general encoding pattern. Another problem with trying to map VSS onto VIWI is that the VIWI leaf nodes (elements) residing under one and the same branch (resource) shall be "logically equivalent" (the same type). As this restriction does not exist in VSS, a mapping will lead to confusion, or worse. In my view, a solution like this will be so full of compromises that it becomes a bad software solution. And we all know where they typically end up. My view is that the VIWI data model can be mapped/ported to VSS, the other way around is not possible without getting into "suboptimal" solutions. As it seems to me that it is not possible for the group to get consensus on porting the VIWI data model to VSS, I cannot see any other way forward than splitting the development up into two tracks, creating two standards. BR Ulf On Tue, Aug 20, 2019 at 11:02 PM Rudolf J Streif <rudolf.streif@ibeeto.com> wrote: > Hi Peter, > > As you say there are a couple of possible locations where the hash can > be calculated: > > * Client: that could be done with a client lib to hide that process from > the developer which is desirable > > * Server: as you say, if the length of the path is more than 3 elements > the server calculates the hash > > * Proxy: all requests are sent to a proxy server that computes the hashes > > Since I have not deployed ViWi and don't know what the reason for the > limitation is I cannot tell what the best method would be (and most > likely there's no one-fits-all solution). > > :rjs > > On 8/20/19 1:52 PM, Winzell, Peter wrote: > > Hi interesting, So that would keep the VSS model and we would have URIs > like Vehicle/256Hash(x.y.z.w.u)/vssleaf_i > > So, then the server would keep a table of the hashed branch which would > generate x.y.z.w.u construct the correct treepath down to the leaf as in > this example…and through its internal data table match the branch with the > actual vehicle signal and return the response. So, hiding the actual hash > compute from the 3party developer we can do with a client API, or we need > to add it somehow to the VIWI protocol( if long ass tree branch in request > try hash else return some error) ? What are your thoughts there? > > > > Br > > Peter Winzell > > > > > > > > > > On 8/20/19, 1:26 PM, "Rudolf J Streif" <rudolf.streif@ibeeto.com> wrote: > > > > Out of curiosity: what is the reason of the tree depth limit to 3 for > > ViWi? Is that a technical limitation of some sorts? > > > > The reason for VSS's essentially unlimited tree structure is > > extensibility. The tree can grow horizontally and vertically as > needed. > > When we created VSS we found this very useful. We purposely tried to > > avoid any limitations. > > > > Another way of possibly overcoming the tree depth limitation and > > potentially providing a more automated way of mapping is to use > hashes > > for the branches of the tree that are omitted. So for Peter's > example: > > > > To replace > > > > Vehicle.Cabin.Seat.Row4.Pos1.Isbelted > > > > with a SHA256 > > > > > /Vehicle/103890db1712299c242c7613e0195d56bd99155dab18e1ad1477a152b2ab3337/Isbelted > > > > Obviously this is not human-readable anymore and since SHA256 is a > > one-way function the REST server can only do a comparison to check > for > > the resource but that comparison is rather quick. A lookup table for > > reverse lookup could easily be created with the VSS processors. > > > > :rjs > > > > On 8/20/19 9:59 AM, Winzell, Peter wrote: > > > Hi Ted, > > > So, could this alternate URI be exemplified ? As this would keep > the VSS model intact? > > > > > > Br > > > Peter Winzell > > > > > > > > > > > > On 8/20/19, 5:22 AM, "Ted Guild" <ted@w3.org> wrote: > > > > > > Regarding tree depth, one idea is to support alternate URIs so > you can > > > have paths that correspond to tree branches and for those to > either > > > transparently proxy or redirect. > > > > > > We remain extremely focused on vehicle signals, they are of > greater > > > interest for more participants than the other 'domains' we'll > want to > > > have in-vehicle services for. We want the protocol to be able > to be > > > able to accommodate them as well. > > > > > > On Mon, 2019-08-19 at 15:58 -0700, Peter Winzell wrote: > > > > Hi All! > > > > Some thoughts for tomorrows’ meeting. Looking at the VIWI > submission > > > > and the VIWI data model and how to keep VSS intact. > > > > For me it seems that the we would try to map the VSS data > model > > > > against the viwi.service.car definition. > > > > > > > > In VIWI we have a number of vehicle data objects defined > such as > > > > car/info. infoObjects where we are able to retrieve the VIN > is one > > > > such object: > > > > > > > > /car/info/<vinidentifier> > > > > > > > > In VSS: > > > > Vehicle.VehicleIdentification.VIN > > > > > > > > In Vss the vin number is defined as the tree branch > > > > Vehicle.VehicleIdentification.VIN > > > > > > > > Vehicle — | > > > > —| > > > > VehicleIndentification —| > > > > VIN > > > > —| > > > > … > > > > … > > > > > > > > In this case we have two tree structures with the depth 3. > This > > > > seems to match pretty well ? > > > > > > > > However, VIWI limits the depth of the tree structure to 3 , > which in > > > > the following example makes VSS incompatible with the > current VIWI > > > > data model : > > > > > > > > In VSS: > > > > Vehicle.Cabin.Seat.Row4.Pos1.Isbelted. > > > > > > > > In this case we would try to match this we would have to > define 3 > > > > more vehicle data objects: > > > > /Vehicle/Cabin/Seat > > > > - available seat objects would be returned by a GET > > > > request, row would be one such object which links to the > > > > /Vehicle/Row/Rowobjects > > > > - available row objects returned by a GET request. > Which > > > > links to positionObjects > > > > /Vehicle/Pos/Positionobjects > > > > — Isbelted element > > > > > > > > This would keep the tree limit - in my view this would > transform the > > > > VSS data model into something not VSS although we have some > sort of > > > > mapping ?. The other way around is not possible since this > would make > > > > the current VIWI model incompatible with present in-vehicle > > > > implementations if I understand correctly. So I now see us > spitting > > > > the spec into two separate tracks where we have VISS/VSS > and VIWI > > > > submitted as the W3C signal specification. I have a feeling > that both > > > > tracks will suffer from adapting to each other/ and in the > end we > > > > could end up with something of inferior technical quality. > For Volvo > > > > cars we see VSS as a key element to the W3C submission and > we want to > > > > continue this work going forward. > > > > > > > > Br > > > > Peter Winzell > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ted Guild <ted@w3.org> > > > W3C Automotive Lead > > > http://www.w3.org > > > > > > > > > > > > > > > > > -- Ulf Bjorkengren *Geotab* Senior Connectivity Strategist | Ph. D. Mobile +45 53562142 Visit www.geotab.com
Received on Wednesday, 21 August 2019 09:25:43 UTC