- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Tue, 3 Sep 2019 10:35:43 -0700
- To: "Luennemann, Patrick (CQTM)" <patrick.luennemann@carmeq.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>
- Message-ID: <b018ff9a-69c6-d5c1-c3a2-34b046f6b7b9@ibeeto.com>
And /<service>/<resource>/<element> would not be the equivalent of VSS leaf? Why not? :rjs On 9/3/19 6:35 AM, Luennemann, Patrick (CQTM) wrote: > Hej everyone, > > I just explained the 3 VIWI levels in the call and wanted to give a textual description as well. > > The three levels in VIWI (be aware, there is a forth) are not comparable to the levels within VSS. > They express a certain idea, certain type. > > /<service> > This is an implementation, a service (if you want to a micro-service) bundling functionality. > It contains resources (lists). > > /<service>/<resource> > This is a list within the service. The service on this level can only have resources (lists). > > /<service>/<resource>/<element> > This is an element. All elements in a resource are of the same type (defined through being in that resource). > An element contains multiple properties. > > /<service>/<resource>/<element> Property > This is a property that holds data. > It has a certain type. > It is the smallest item that can be filtered for. > > > /Patrick > > -- > Patrick Lünnemann > CQTM / Carmeq GmbH > Telefon: +49 160 901 319 84 > > -----Original Message----- > From: Rudolf J Streif <rudolf.streif@ibeeto.com> > Sent: Dienstag, 20. August 2019 22:26 > To: 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 > > 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 >> >> >> -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700
Received on Tuesday, 3 September 2019 17:36:11 UTC