- From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- Date: Tue, 21 Jan 2020 17:19:30 +0100
- To: Rudolf J Streif <rudolf.streif@ibeeto.com>, "Daniel.DW.Wilms" <daniel.dw.wilms@bmw.de>
- Cc: Magnus Feuer <mfeuer1@jaguarlandrover.com>, Gunnar Andersson <gandersson@genivi.org>, W3C Public Automotive <public-automotive@w3.org>
- Message-ID: <CAHfMbK99DbM+r3UWmOTPTHq+mDMa9fPmM4Yr9ew_SSRZXECoXQ@mail.gmail.com>
I am also in doubt of its usefulness. With generic rules on what is allowed to do with node metadata, and complete nodes, as discussed by @Daniel.DW.Wilms <daniel.dw.wilms@bmw.de> and me, I think the layer data do not need any attribute defining what it does. BR Ulf On Tue, Jan 21, 2020 at 4:33 PM Rudolf J Streif <rudolf.streif@ibeeto.com> wrote: > I thought about using an attribute to define what an overlay does before. > I came to the conclusion that it is not that good of a solution as it makes > adoption of somebody else's overlay tree quite complex as you have to go > through every single file and look if you like the overlay or not. > > > If the whole concept of it is really necessary, and I am not quite sold on > that in the first place, then there should be a toplevel way of doing it. > > > :rjs > > > On 1/20/20 12:17 PM, Magnus Feuer wrote: > > Late to the party, as per usual. > > We do very much need layers. As Ulf and Rudi pointed out, we need to think > about removing both metadata and whole branches, for example when a single > instance of something needs to be replaced by an enumerated list of > instances. > > A somewhat silly example is if we have multiple IVI systems, which > necessitates the following change: > > ...Infotainment.[subtree] -> ...Infotainment.1.[subtree], > ...Infotainment.2.[subtree]... > > In this case the existing "...Infotainment.[subtree]" needs to be deleted > since it would interfere with the enumerated list of IVIs. > > One (somewhat over-engineered) solution would be to add metadata > (attribute) to the overlay file's the branch, specifying how the overlay > should be applied: > > # > # I am an overlay file that modifies an existing tree. > # > - Vehicle.Cabin.Infotainment: > type: branch > * overlay: replace* # or one of extend, modify, modify_and_extend. > > - Vehicle.Cabin.Infotainment.1: > type: branch > ... > > The overlay attribute can be one of: > *extend* > The overlay extends an existing branch in the signal spec, but does not > modify existing signals. If an existing signal is re-defined by the > overlay, an error is thrown. > Metadata can be added to existing signals. > > *modify* > The overlay modifies existing branches and signals in the original spec. > If a signal (or branch) does not exist in the original, an error is thrown. > Metadata can be added to existing signals. > > *modify_and_extend [default]* > The overlay can both modify existing branches and signals, and create new > one. > > *replace* > The entire branch is cleared from the original specification, and only the > structure defined in the overlay will be used. > > Would that 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 J Streif > *Sent:* Monday, January 20, 2020 10:44 > *To:* Ulf Bjorkengren > *Cc:* Gunnar Andersson; W3C Public Automotive > *Subject:* Re: VSS Layers introduction > > 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> > 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 > > > > -- > ----- > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3386 x700 > > -- > ----- > 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
Received on Tuesday, 21 January 2020 16:19:47 UTC