- From: Rudolf Streif <rudolf.streif@ibeeto.com>
- Date: Wed, 21 Aug 2019 13:31:05 -0700
- To: "Winzell, Peter" <peter.winzell@volvocars.com>
- Cc: "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>, Ulf Bjorkengren <ulfbjorkengren@geotab.com>, "ted@w3.org" <ted@w3.org>, Peter Winzell <peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org>
- Message-ID: <CAPxNcnfA59M7BLuLLrJC_yRMa_retahDnBkOHW2=AgMA2Hq_Ug@mail.gmail.com>
@Peter, Yes, that is correct. However, because we are talking hashes the mapping can unambiguously be computed at any time. Since a web server typically does not have an issue with many segments in a path, ViWi's limitation must be somewhere in the backend. @Magnus Feuer, that is exactly where a uuid differs from a hash. A uuid is unique but the generator algorithm has no input hence it cannot be re-computed and consequently a lookup table is required. :rjs On Wed, Aug 21, 2019, 10:58 Winzell, Peter <peter.winzell@volvocars.com> wrote: > Hi Rudy, > > > > “But what can be done with an entire path can be done with any node in the > path” > > So this in practice would mean a mapping from all vertices over all edges > to achieve a complete mapping of the VSS graph below the vehicle node? > > A very tiny VSS graph : > > > > > > Vehicle.A.B.C > > Vehicle.A.B.D > > > > We would need mapping and corresponding hash for A – B , A – B – C, A – > B – D. Or am I misunderstanding … > > > > “Accordingly it would be best to analyze the limitations”… could you > elaborate on what you are suggesting here. > > > > Example : > > The current limitation of depth 3 in the VIWI data model makes it more > complex to map the VSS data model to the VIWI protocol that I think we all > can agree to. So just as an example(I am not suggesting this ) if we use > the hash scheme for vertices/nodes to leaf as in your example and disallow > any other paths such which would suggest multiple branches to leafs , that > would reduce complexity. > > > > Br > > Peter Winzell > > > > *From: *Rudolf Streif <rudolf.streif@ibeeto.com> > *Date: *Wednesday, August 21, 2019 at 9:48 AM > *To: *"Gavigan, Kevin" <kgavigan@jaguarlandrover.com> > *Cc: *Ulf Bjorkengren <ulfbjorkengren@geotab.com>, "Winzell, Peter" < > peter.winzell@volvocars.com>, "ted@w3.org" <ted@w3.org>, peter winzell < > peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org> > *Subject: *Re: VSS and VIWI > > > > I fully agree with Kevin. It is the nature of mapping that some > information and/or functionality is not available anymore. Just think > geographic maps. That does not render them useless. > > > > The idea I proposed is to use a hash to encode the entire path from root > to leaf. That is actually not that novel for VSS. Well, the hash is but > from the beginning we had a processor that simply assigned a number to the > nodes. Obviously the numbering is not that great as it can change when the > table is recreated. The hash is much better for that. > > > > My example encoded the entire path from root to leaf. Ulf is correct that > with that you cannot access a whole part of the branch anymore. But what > can be done with an entire path can be done with any node in the path. > > > > Regardless, what Kevin says holds true, the limitation is the limited > depth of ViWi. Accordingly it would be best to analyze the limitations and > see how it can be overcome rather than work around it. > > > > :rjs > > > > On Wed, Aug 21, 2019, 03:48 Kevin Gavigan <kgavigan@jaguarlandrover.com> > wrote: > > Hi, > > > > [Apologies for only engaging when debate and discussion are well underway] > > > > >> more complex VSS branch structures (depth more than 3, with > sub-branches) will have to be represented as multiple 3-level VIWI branches. > > > > Believe the issue is a more general one (and the above is an example of > the complexity that is introduced as a consequence of the ‘3-level limit’. > > > > If the logical (directed, acyclic) object graph (that is being used to > represent an instance in a particular domain) naturally has more than 3 > logical levels (which many do), then any specification that defines an API > that assumes up to 3 levels will need to return data that has either been > adapted in some way (e.g. as Rudi proposed) or will need to return a > complex object graph when querying reaches level 3, and this complex object > will require further parsing to obtain a value nested arbitrarily deep > within the object. > > > > Hence same limitations and/or mapping problems will arise regardless of > the domain that the object graph is concerned with (not just with VSS). > > > > So believe the 3 level limit is key here… > > > > [Didn’t mean to stir things up, just to argue that (imho) problem is a > general one….] > > > > Regards and best wishes, > > > > Kev > > > > *From:* Ulf Bjorkengren [mailto:ulfbjorkengren@geotab.com] > *Sent:* 21 August 2019 10:25 > *To:* Rudolf J Streif <rudolf.streif@ibeeto.com> > *Cc:* Winzell, Peter <peter.winzell@volvocars.com>; ted@w3.org; Peter > Winzell <peter.winzell@jayway.com>; public-automotive < > public-automotive@w3.org> > *Subject:* Re: VSS and VIWI > > > > 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 > <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C61dfd84272c647578aa808d72657541e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637020028852441661&sdata=sOT65VBTo0hCBs%2B7kBwJMoYJ%2FCcrIdjlQ7V2sC2rxFg%3D&reserved=0> > > > > > > > > > > > > > > > > > > > > -- > > *Ulf Bjorkengren* > > *Geotab* > > Senior Connectivity Strategist | Ph. D. > > Mobile > > +45 53562142 > > Visit > > www.geotab.com > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geotab.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C61dfd84272c647578aa808d72657541e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637020028852451657&sdata=x4Ac0uREqxxor3HrHWGV%2F4VKNTc9l1e%2F7BZ4gkTBBos%3D&reserved=0> > > > >
Attachments
- image/png attachment: image001.png
Received on Wednesday, 21 August 2019 20:31:43 UTC