- From: Rudolf J Streif <rudolf.streif@ibeeto.com>
- Date: Tue, 21 Jan 2020 08:32:12 -0800
- To: Ulf Bjorkengren <ulfbjorkengren@geotab.com>, Gunnar Andersson <gandersson@genivi.org>, "Daniel.DW.Wilms" <daniel.dw.wilms@bmw.de>
- Cc: "mfeuer1@jaguarlandrover.com" <mfeuer1@jaguarlandrover.com>, "public-automotive@w3.org" <public-automotive@w3.org>
- Message-ID: <5b37f6d5-51fe-07ae-a761-ed6f068eebbf@ibeeto.com>
I am inlining below. On 1/21/20 5:07 AM, Ulf Bjorkengren wrote: > I think the argument by @Gunnar Andersson > <mailto:gandersson@genivi.org> "It also ensures that files are close > to the files they modify." is quite strong, and together with his > other arguments convinces me that is the way to go. > I am not quite sure on how to interpret "files are close to the files they modify." If that means that an overlay file resides, or stronger, has to reside, within the same directory than the original vspec file is amends then, in my opinion, this defeats the purpose of layers in its roots. The two main use cases that drove the current implementation are: 1. The VSS provided by W3C defines the signals and their basic attributes as a agreed-upon standard. OEMs will have to override attributes such as min, max values, default settings etc. You do that most effectively by overlaying an entire OEM tree that specifies the modifications only on top of the standardized VSS. That does not just mean one overlay per OEM but of course can mean different overlays for different vehicle models and, as discussed below, for different target markets. Attempting to do that with overlay files added to the original VSS tree then it becomes unmanageable and it would be simpler to just modify the original files directly. 2. Adding attributes, or metadata, to existing node definitions such as CAN DB entries. 3. OEMs, or anybody else adding new signals, can define entire signal trees that get added to the standardized tree. That is a reasonable thing to do. In my opinion a standard is most valuable when it standardizes items for shared use and interoperability but allows extensions using the same model where such is not required or desirable. That would not at all be possible if there is a requirement that all layer files have to be integrated into the already existing, and standardized, structure. > @Daniel.DW.Wilms <mailto:daniel.dw.wilms@bmw.de> brings up important > questions of adding/overwriting/removing metadata, and adding/removing > complete nodes. > After reflecting on it, this is my current view on what the layering > should be allowed to do: > - add metadata: the main purpose of the layering, should be allowed. +1, that is use case 2. above. > - overwrite metadata: Not allowed for type, data type, enum, and maybe > more. Allowed for instance, description, unit?, and maybe more. +/-0. I understand the rationale as it would counteract the standardization. However, the standard defines runtime metadata query hence good implementation could be adapt to that. However, I would agree that fixing data types makes things easier for programming languages with strong compile time typing. > - remove metadata: Not allowed. +1, it would counteract standardization. > - add node: Allowed. Only by adding to existing structure, paths to > existing leaves must not be changed. +1, that is use case 3. above. > - remove node: Allowed (only leaf nodes, and resulting "empty" subtrees). +1, albeit it somewhat counteracts standardization, it, for instance, makes no sense to carry signals for ICE engines in a VSS tree for electric vehicles. > > I think that the "layering" function shall be handled by a separate > tool from the "transformation" tool (transform from YAML to other > format), to allow for an inspection of the layering result before > transformation (and instantiation), and to reduce the complexity of > the tools. > I am not sure if that requires a different tool.The existing tool can easily be modified to output log information on what nodes have been modified how through layering. :rjs > BR > Ulf > > On Tue, Jan 21, 2020 at 7:23 AM Gunnar Andersson > <gandersson@genivi.org <mailto:gandersson@genivi.org>> wrote: > > Thanks everyone for input, and sorry for the top post. Bad mail > client, and limited time. > > It is perhaps not "meant" to have multiple layers, it is just a > possibility. I am uncertain if you misunderstood or if I am > reading your questions wrong. But generally, yes, I am proposing > separating different concerns in different files, especially if > the variability is such that composability of those layers models > the reality in a good way. And I expect more variability than > only "market". > > The purpose of mentioning markets was just an example where we > have variability and therefore it is (one) reason to put the > variable part in a layer, so that you can keep the constant part > (the standard vspec for example) unchanged. We agree on the > premise so far? > > In my view the market specific info is a layer, but with multiple > instances (one per market). > You exchange the version of that layer when it needs changing (a > file version per market, or whatever other thing is being > modeled. They are instances of the concept being modeled). > > If this does not fit market specific info then maybe we look at > other ways there. I still think the layer concept is the generic > tool for this type of stuff, but we could drill into market > variations to see if it works. > > Complex? I think (hope) I am only proposing a generic optional > tool/approach here and that any complexity stems from the reality > that is modeled, primarily. > > Is a single deployment file enough, you ask? I dont know without > understanding its content... I do not immediately see how it > solves the variability/composability problem, but I could be wrong. > > > "a top level directory, where we can add the deployment files" > > For better or worse, the vspec interpretation depends on the > directory structure, so I proposed the same for extensions. Do > you use a different way to define the node path in the extension > files? My default was to aim for consistency first and a minimal > amount of extra new rules/exceptions. It also ensures that files > are close to the files they modify. It seems straight forward to > me... > > Anyway, the input from Rudi explains the implementation is also > quite flexible in how you interpret files. I think the key is to > agree on convention or best practice and describe that too, for > real world modeling scenarios. I mean current python tools in the > repo is one thing and the formal specification > (rules/recommendations/conventions) of what VSS *is*, is another. > The latter is possibly more important to agree on. Because tools > will be written and extended over time in any case. > > > -- > Gunnar Andersson <gandersson@genivi.org > <mailto:gandersson@genivi.org>> > Development Lead, GENIVI Alliance > > ------------------------------------------------------------------------ > *From:* Daniel.DW.Wilms@bmw.de <mailto:Daniel.DW.Wilms@bmw.de> > *Sent:* Monday, January 20, 2020 21:24 > *To:* mfeuer1@jaguarlandrover.com > <mailto:mfeuer1@jaguarlandrover.com>; rudolf.streif@ibeeto.com > <mailto:rudolf.streif@ibeeto.com>; ulfbjorkengren@geotab.com > <mailto:ulfbjorkengren@geotab.com> > *Cc:* gandersson@genivi.org <mailto:gandersson@genivi.org>; > public-automotive@w3.org <mailto:public-automotive@w3.org> > *Subject:* Re: VSS Layers introduction > > Hi, > > > > First of all thanks @Gunnar for sharing the presentation. I really > like the concept. I don’t have much to add, as it maps almost one > to one how we do it. I would have two remarks from our experience: > > 1. From slide 7 I understood, that it’s meant to have multiple > layers on top of each other.But that gets pretty complex then, > doesn’t it? I agree that you have to support different markets > etc., but can’t you put those specifics into one layer? We > called the same concept “deployment”, where we collect the > additional meta-data for one specific deployment and it > contains everything, which is needed for the system where the > tree gets deployed. Maybe that’s enough to keep the complexity > manageable? > 2. Slide 9: You mention that the directory/file structure should > be the same, just a different suffix. We started doing it the > same way, but noticed that it quickly was hard to maintain. > For the spec it works as it’s more stable, but on a > deployment/layer level, which constantly changes and needs > adaptation, it was pretty hard to keep the overview. So we > decided to go for a top level directory, where we can add the > deployment files and where one file contains the additional > meta information. We saw that it was much easier to handle. > > > > >> 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? > > > > I think removing nodes is not an issue. The moment you don’t add > any additional meta information to a leaf it’s removed in the > deployment of the tree. If a subtree doesn’t have any leaf it’s > removed as well, etc. > > > > Removing meta-data would change the spec quite heavily. Should it > be supported? Further, fields like datatype, unit, etc. shouldn’t > be overwritten, because that’s the core of the specification. > Maybe instances would be some natural candidate to be overwritten. > > > > > 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. > > > > Adding nodes shouldn’t be supported through layers. Wouldn’t it be > done through the spec and not the meta information? If not public, > it would be the private branch. Otherwise it kills reusability. > You would have to know each and every layer to get the full > picture of the tree. Further, you end up with different naming, > data-types, etc. Even on a private level you don’t want to go there. > > > Daniel > > > > --- > > *BMW Technology Office Israel* > > Daniel Wilms > > Research Engineer > > > > phone: +972 54 34 20 806 > > mail: _daniel.dw.wilms@bmwgroup.com > <mailto:daniel.dw.wilms@bmwgroup.com>_ > > > > postal address: > > BMW Technology Office Israel Ltd > > 121 Menachem Begin Road > > LABS Mailbox numbers: 93-95 > > Tel Aviv > > Israel 8067318 > > > > > > > > *From: *Magnus Feuer <mfeuer1@jaguarlandrover.com > <mailto:mfeuer1@jaguarlandrover.com>> > *Date: *Monday, 20 January 2020 at 10:18 PM > *To: *Rudolf J Streif <rudolf.streif@ibeeto.com > <mailto:rudolf.streif@ibeeto.com>>, Ulf Bjorkengren > <ulfbjorkengren@geotab.com <mailto:ulfbjorkengren@geotab.com>> > *Cc: *Gunnar Andersson <gandersson@genivi.org > <mailto:gandersson@genivi.org>>, W3C Public Automotive > <public-automotive@w3.org <mailto:public-automotive@w3.org>> > *Subject: *Re: VSS Layers introduction > *Resent-From: *<public-automotive@w3.org > <mailto:public-automotive@w3.org>> > *Resent-Date: *Monday, 20 January 2020 at 10:17 PM > > > > 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 > <mailto:mfeuer1@jaguarlandrover.com> > *Mobile*: +1 949 294 7871 > > > > Image removed by sender. > > > 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 <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 > > > > -- > 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 Tuesday, 21 January 2020 16:32:24 UTC