Re: VSS Layers introduction

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