Re: VSS and VIWI

@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>
>
>
>
>