- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Mon, 20 Jan 2020 10:44:50 -0800
- To: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- Cc: Gunnar Andersson <gandersson@genivi.org>, W3C Public Automotive <public-automotive@w3.org>
- Message-ID: <3e1a921d-8e04-bdb7-6688-edfe0a41ed44@ibeeto.com>
Hi Ulf, > I like that the VSS layers model as I understood it takes as input "layer files" with the same filename, but different extension, located in the same directory as the > vspec file that they are to update. Actually that is not how it currently works. The overlay files can have different names and are in different directories. What is important is the branch name of the nodes and that they files are included at the right position in the tree. That means, yes, you can have a file with a different name (including extension) in the same directory and include it there or you can have a full directory tree starting at the root. And of course anything between these two "extremes". > With this model we will have the existing tool(s) that transform the vspec YAML format to other formats (JSON, csv, etc), and new tool(s) that use the YAML layers to > modify the YAML vspec files. The converter tools already handle that. > Adding or overriding metadata in nodes should be straight forward. Removing metadata in nodes needs a little more design thinking, maybe with a separate "remove- > tool" and layer files? Removing nodes from the default tree through an extension tree is a use case that has not yet been discussed. > What to me seems more complicated is to add or remove nodes, is that something that should be supported? Adding nodes is supported. The whole scheme is actually pretty simple if a node already exists when an extension/layer file is processed then the fields get updated (or added for that matter if a field does not yet exist e.g. CAN DB field). If a node does not yet exist it will be added. :rjs On 1/20/20 5:36 AM, Ulf Bjorkengren wrote: > I like that the VSS layers model as I understood it takes as input > "layer files" with the same filename, but different extension, located > in the same directory as the vspec file that they are to update. > With this model we will have the existing tool(s) that transform the > vspec YAML format to other formats (JSON, csv, etc), and new tool(s) > that use the YAML layers to modify the YAML vspec files. > Adding or overriding metadata in nodes should be straight forward. > Removing metadata in nodes needs a little more design thinking, maybe > with a separate "remove-tool" and layer files? > What to me seems more complicated is to add or remove nodes, is that > something that should be supported? > > On Fri, Jan 17, 2020 at 7:31 PM Rudolf J Streif > <rudolf.streif@ibeeto.com <mailto:rudolf.streif@ibeeto.com>> wrote: > > Actually this statement is not quite correct: > > 1) Potential for *any number of* layers. (As of now the private branch > acts as a *one* additional "layer" that can override and add data, as > you now described) > > > It's not limited to a branch called 'private'. What branch is > merged and > where is defined by an include in the toplevel > VehicleSignalSpecification.vspec. Now of course this begs the question > what happens if there are multiple includes that modify/amend the same > nodes when there are conflicts? The answer is: "the last one wins" as > the includes are processed in order of appearance in > VehicleSignalSpecification.vspec. That essentially constitutes an > implicit priority. > > Layer priority is probably something that you want to add to the slide > "Additional design challenges". > > :rjs > > On 1/16/20 9:52 PM, Gunnar Andersson wrote: > > > > Thanks for pointing that out, Rudi. > > > > (continued...) > > > > On Wed, 2020-01-15 at 09:32 -0800, Rudolf J Streif wrote: > >> Functionality of appending and/or modifying a node from one branch > >> with > >> a node from another branch with the same signal path is already > >> available in VSS. > > [trimmed] > > > >> > https://github.com/GENIVI/vehicle_signal_specification/commit/518dfbeb2a434c9c55ec27e06c84f6e8caf941bd#diff-4a931512ce65bdc9ca6808adf92d8783 > >> > > That's great and shows that this thinking was there from the > beginning. > > That commit indeed provides an implementation that is a starting > point > > for the behavior that this proposal looks for. > > > >>> The commit message states: > > [trimmed] > > > >> Now that does not cover everything from Gunnar's slides (in > >> particular > >> there is no wildcard support) but it's a starting point. > > Yes. And a few other differences that come to mind. These are > things > > that might be added on top of the current model, *if* the layers > idea > > were adopted: > > > > 1) Potential for *any number of* layers. (As of now the private > branch > > acts as a *one* additional "layer" that can override and add > data, as > > you now described) > > > > 2) A proposal of layers as parallell files in the same directory > tree > > -- with different file suffix -- (it would complement the current > > model that places /private as a parallel directory subtree) > > > > 3) The presentation hints at some additional higher level > concepts that > > would allow defining metadata about the layers themselves. > > and as a corrollary it also suggests that we are effectively > defining > > some varying file types. I.e. they might not be formally > .vspec" files > > but something else. (The current /private "layer" does not > explicitly > > make a distinction, and basically assumes ".vspec" files to be > there). > > I'm not sure how important that is but it seemed useful to me. > > > > > > Best Regards, > > - Gunnar > > > > P.S. Since we are now talking about VSS specifics, I expect the > details > > of this will be sorted out using GitHub issues, but if it is in the > > interest of the W3C participants then of course by all means > feel free > > to continue the discussion here. > > > > > > > > > > > > > > It's a great start however. > > > >> :rjs > >> > >> On 1/14/20 12:26 PM, Gunnar Andersson wrote: > >>> As requested today, here is a link to the introduction/rationale > >>> slides > >>> for "VSS Layers". > >>> > >>> A small caveat, this presentation is a work in progress and > >>> describes > >>> the rationale on a very fundamental level. The idea is simple of > >>> course, and very generic, because it is useful/needed in a whole > >>> bunch > >>> of areas, not only for access control even if that that was one of > >>> the > >>> driving areas. > >>> > >>> There of course needs to be some work to tie this into the W3C > >>> protocol > >>> specifics by means of examples etc. We concluded today that it is > >>> basically in line with what is needed in Ulf's recent > >>> implementation > >>> work as well as previous similar things that Daniel mentioned had > >>> been > >>> tried in his organization in the past, so hopefully this is > useful, > >>> even if it does not today provide all the concrete examples in the > >>> W3C > >>> protocol context. > >>> > >>> Happy to have the discussion about comparing this to previous > >>> similar > >>> ideas and to define more of the details. > >>> > >>> Thanks, > >>> - Gunnar > >>> > >>> [1] > >>> > https://at.projects.genivi.org/wiki/pages/viewpageattachments.action?pageId=40402952&sortBy=date&highlight=VSS+composable+layers+-+draft+20200114.pdf&&preview=/40402952/47711024/VSS%20composable%20layers%20-%20draft%2020200114.pdf > >>> > >>> or shorter: > >>> https://bit.ly/2TnrV05 > >>> > > > -- > ----- > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3386 x700 > > > > > -- > Ulf Bjorkengren > *Geotab* > Senior Connectivity Strategist | Ph. D. > Mobile +45 53562142 > Visit www.geotab.com <https://www.geotab.com/> > > > -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700
Received on Monday, 20 January 2020 18:44:59 UTC