- From: Ted Guild <ted@w3.org>
- Date: Mon, 26 Aug 2019 10:03:56 -0400
- To: Magnus Feuer <mfeuer1@jaguarlandrover.com>, Rudolf Streif <rudolf.streif@ibeeto.com>, Kevin Gavigan <kgavigan@jaguarlandrover.com>
- Cc: Ulf Bjorkengren <ulfbjorkengren@geotab.com>, "Winzell, Peter" <peter.winzell@volvocars.com>, Peter Winzell <peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org>
- Message-ID: <be73db38eee9cf71b9ce018513e87be613f5bc93.camel@w3.org>
On Wed, 2019-08-21 at 17:40 +0000, Magnus Feuer wrote:
> Late to the game, as per usual.
>
> JLR is engaging with the VSS-part of our effort and (at least
> currently) less with its sibling projects. We would prefer if the
> core structure of the tree, such as the strategy for specifying
> physical seat position, arrays, etc, can be stabilized within the
> coming months.
>
> Up until then I am all for changes and will do what I can do carry
> them out.
>
> As for SHA256, I humbly point you to:
> https://github.com/GENIVI/vehicle_signal_specification/issues/102
As ViWi uses uuid already, why not use those from VSS instead of SHA256
as our hash?
> From the generated JSON file:
>
> "Lateral": {
> "description": "Vehicle acceleration in Y (lateral
> acceleration).",
> "datatype": "int32",
> "type": "sensor",
> "uuid": "5c28427f79ca5fe394b47fe057a2af9b",
> "unit": "m/s2"
> },
>
> So signal ID has already been replace with a UUID.
>
> If we, in this thread, agree to change the scheme I will happily do
> the work.
>
> /Magnus F.
> -------------------
> System Architect Manager
> Jaguar Land Rover
>
> Email: mfeuer1@jaguarlandrover.com
> Mobile: +1 949 294 7871
>
>
>
> Jaguar Land Rover North America, LLC
> 1450 NW 18th Ave, Portland, OR 97209
> -------------------
> Business Details:
> Jaguar Land Rover Limited
> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
> Registered in England No: 1672070
>
> This e-mail and any attachments contain confidential information for
> a specific individual and purpose. The information is private and
> privileged and intended solely for the use of the individual to whom
> it is addressed. If you are not the intended recipient, please e-
> mail us immediately. We apologise for any inconvenience caused but
> you are hereby notified that any disclosure, copying or distribution
> or the taking of any action in reliance on the information contained
> herein is strictly prohibited.
>
> This e-mail does not constitute an order for goods or services unless
> accompanied by an official purchase order.
>
>
> From: Rudolf Streif <rudolf.streif@ibeeto.com>
> Sent: Wednesday, August 21, 2019 09:47
> To: Kevin Gavigan <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/103890db1712299c242c7613e0195d56bd99155dab18e1ad1477a15
> > > 2b2ab3337/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
> >
--
Ted Guild <ted@w3.org>
W3C Automotive Lead
http://www.w3.org
Received on Monday, 26 August 2019 14:04:09 UTC