> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Sean
> Barnum
> Sent: Tuesday, April 6, 2021 8:40 AM
> To: Alexios Zavras <[email protected]>; Robert A Martin
> <[email protected]>; Henk Birkholz <[email protected]>
> Cc: [email protected]
> Subject: Re: [EXT] Re: [spdx-tech] interactions between profiles
...
> In general if you define a subprofile or another profile, then the constraints
> are only allowed to narrow and not broaden. In this way all content of the
> subprofile is also valid according to the parent profile.
> Think of profiles as venn diagrams of content expressible by the model.
[G.O.] So for Alexios' examples below, can you answer which specifically is
allowed? For example, can you add additional enumerations?
>
> So, I think the discussion around adding or modifying in profiles may be
> confusing the model with the profiles defined against it.
> Profiles should never add to or modify the model. They simply identify
> portions of the model and how they should be used (constraints) for a given
> context.
>
> Sean Barnum
> C – 703-473-8262
> [email protected]
> We are here to change the world!
> <https://www.facebook.com/MITREcorp>
> <https://www.linkedin.com/company/mitre>
> <https://twitter.com/MITREcorp>
> <https://www.youtube.com/user/mitrecorp>
> <https://plus.google.com/+MitreOrgFFRDCs/posts>
> <http://www.mitre.org/>
>
>
>
> On 4/6/21, 6:55 AM, "[email protected] on behalf of Alexios Zavras"
> <[email protected] on behalf of [email protected]> wrote:
>
> Right.
>
> Henk, it might be useful to think that our "profiles" are similar to
> "Bluetooth
> profiles", listed in https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles.
> Each one (like Headset profile, or Serial Port Profile) adds some new
> information and a specific device might use only a couple of them.
>
> Our problems, discussed in this thread, comes from the interaction between
> profiles.
>
>
> [sorry for following up so late -- Easter holidays]
>
> -- zvr
>
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of
> Martin, Robert A
> Sent: Thursday, 1 April, 2021 21:11
> To: Henk Birkholz <[email protected]>; Gary O'Neall
> <[email protected]>; [email protected]; Spdx-
> [email protected]
> Subject: Re: [EXT] Re: [spdx-tech] interactions between profiles
>
> Hi all,
>
> At the risk of adding confusion but the intention of helping bring
> clarity I will
> offer that the idea is to have a specification with a core that is always
> needed
> and then other portions (profiles) of the specification are only used when
> needed for specific use cases/communities.
>
> The specification needs to all fit together and work as a whole for the
> composition of use cases but if I only want to exchange generic BOMs I would
> only need the core. If I want to exchange information about software or
> hardware I would want the profiles for software and/or hardware along with
> the core.
>
> If you want to exchange license information about software you would want
> the core, the software profile and the license profile.
>
> Similarly if you want to exchange provenance information about hardware
> or software you would add in the provenance profile to the core and the
> hardware or software profiles.
>
> In the Object Management Group this concept is captured by stating
> compliance points - subsets of the overall specification that can be claimed
> conformance with/support of.
>
> Hope that helped some,
>
> Bob
>
> Robert (Bob) Martin
> Sr. Software and Supply Chain Assurance Principal Eng.
> Cross Cutting Solutions and Innovation Dept Cyber Solutions Innovation
> Center MITRE Labs MITRE Corporation 781-271-3001o 781-424-4095c
>
> On 4/1/21 2:46 PM, Henk Birkholz wrote:
> > Hi all,
> >
> > I was blocked from attending the last meeting and I really like the
> > activity on the list here right now.
> >
> > Please bear with me while I might open yet another potential can of
> > worms right now (only on the naming level, not on the concept level).
> >
> > Am I mistaken in this context when I think of a profile literally to
> > be a subset of a model? I think I read somewhere in the replies that a
> > profile will add new things. That was quite surprising to me as I
> > would think of that as an extension (sometimes named an augment). A
> > profile specification can go hand-in-hand with an extension
> > specification, of course. But to not potentially violate a principle
> > of least surprise here, I'd like to throw a proposal into the ring
> > here that is not to mix up these two kinds of "follow-up"
> specifications.
> >
> > Viele Grüße,
> >
> > Henk
> >
> > On 01.04.21 20:33, Gary O'Neall wrote:
> >> Responses to both William and Alexios below.
> >>
> >> I like the way Alexios framed up the conversation. Perhaps we should
> >> revisit what changes are allowed, being quite specific this time
> >> around. Once we agree on that, we can go back to the discussion on
> >> how we represent those changes in the information model, the
> >> serialization schemas, and the spec documentation.
> >>
> >> Gary
> >>
> >> *From:* [email protected] <[email protected]> *On
> >> Behalf Of *William Bartholomew via lists.spdx.org
> >> *Sent:* Thursday, April 1, 2021 9:03 AM
> >> *To:* [email protected]
> >> *Subject:* Re: [spdx-tech] interactions between profiles
> >>
> >> I know I missed the beginning of the call so apologies if I'm
> >> re-opening a can of worms, but I'm a big fan of immutability, what
> >> would the world look like if we only supported create (I'd include
> >> extending an enum in this category)? What wouldn't be possible? For
> >> the things that aren't possible can we come up with a way to make
> >> them possible with create instead of modify?
> >>
> >> William
> >>
> >> */[G.O.] I think there is a number of use cases where changing the
> >> cardinality of field is required. An example pointed out on the call
> >> was version. Currently it is optional, but in a security profile or
> >> integrity profile it may be required. On the call, we did discuss
> >> the version example in depth and explored creating a separate Field
> >> just for the profile – but that got really messy./*
> >>
> >> */Another consideration is that supporting “create” at one level
> >> implies “modifiy” at another. For example, creating a new enum value
> >> modifies the enum restrictions in the schema (or the enum class)./*
> >>
> >> */One way to keep the base profile classes immutable, is to subclass
> >> them in the profiles. However, there we ran into the multiple
> >> inheritance problem described below./*
> >>
> >> */To put some context around these discussions, on the call we
> >> arrived at the problem statement and options after trying to figure
> >> out how to map the spec document to our serialization schemas that we
> >> currently support for the SPDX spec. On the call, we used the JSON
> >> Schema
> >> <https://github.com/spdx/spdx-
> spec/blob/development/v2.2.1/schemas/sp
> >> dx-schema.json> as an example since many of the participants are more
> >> familiar with JSON than RDF. This is a bit different and more
> >> detailed than working through the information model. The problem
> >> comes when we want to support an SPDX document that supports more
> >> than one profile (e.g. both defects/security and licensing). This is
> >> where the multiple inheritance problem came in. If in the profiles
> >> we subclass every class that we modify (e.g. we want to change
> >> package version from optional to mandatory for security and make a
> >> required copyright field for licensing), then there would be 2
> >> subclasses of package for each file. Then when we wanted to
> >> represent this in a single schema file, we’re trying to inherit from
> >> 2 classes – the subclass which modifies the package for the license
> >> profile and the subclass that modifies the package for the security
> >> related profile./*
> >>
> >> On 4/1/21 8:54 AM, Alexios Zavras wrote:
> >>
> >> Hi all,
> >>
> >> Following the extremely interesting and intellectually
> >> stimulating
> >> discussion on the SPDX Tech call on Tuesday, I thought I'd try
> >> and
> >> list the interactions between profiles that may exist. These gave
> >> us
> >> some head-scratching moments when we tried to model them.
> >>
> >> We all understand that, if we are going to have a number of
> >> profiles, each one of them will include some new information (for
> >> example, new fields). It may also affect some of the information
> >> defined outside this profile (for example, making a field
> >> mandatory).
> >>
> >> In an effort to “formalize” things, I'll be using abstract terms
> >> like Object, Field, and Type -- I hope we all understand the
> >> general
> >> meaning, even though our specification is not using these terms.
> >>
> >> */[G.O.] I’m assuming Object is equivalent to Class for the
> >> purposes
> >> of our discussion – let me know if I’m wrong on this./*
> >>
> >> So, a profile may do one or more of the following:
> >>
> >> [CREATE]
> >>
> >> 1. define new Fields
> >>
> >> 2. define new Types (used in new Fields)
> >>
> >> 3. define new Objects, with included Fields of certain Types
> >>
> >> [MODIFY]
> >>
> >> 4. add new Fields (with their Types) to Objects defined elsewhere
> >>
> >> 5. change the cardinality of Fields defined elsewhere (and thus
> >> change optional/mandatory status)
> >>
> >> 6. extend an Enum in a Type defined elsewhere, adding more
> >> alternatives (typical case: adding more Relationship types)
> >>
> >> All these were mentioned during the call.
> >>
> >> I assume removing/deleting Fields or Objects is not possible
> >> (right?). What about:
> >>
> >> 7. restrict an Enum in a Type defined elsewhere, removing some
> >> alternatives ?
> >>
> >> As an example, could a profile introduce something like a "Secure
> >> Checksum" idea that says that FileCheksum may NOT be of MD2 type?
> >>
> >> */[G.O.] I hope not. For the example, I can think of some other
> >> approaches which would fit into the Modify and Create category
> (e.g.
> >> create a new field SecureChecksum or have a required enum value
> >> which is a subset of all allowed values)./*
> >>
> >> */Once we agree on the types of changes allowed in a profile, we
> >> can
> >> analyze possible conflicts between the profiles. If we restrict
> >> changes to the add and modify categories above, I can only think
> >> of
> >> a small set of conflicts (e.g. 2 profiles choose the same Field
> >> name
> >> with different types./*
> >>
> >> Hope this helps show what we’re dealing with.
> >>
> >> -- zvr
> >>
> >> Intel Deutschland GmbH
> >> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> >> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> >> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany
> >> Doon
> >> Silva
> >> Chairperson of the Supervisory Board: Nicole Lau
> >> Registered Office: Munich
> >> Commercial Register: Amtsgericht Muenchen HRB 186928
> >>
> >>
> >
> >
> >
> >
> >
> > .
>
>
>
>
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>
>
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4027): https://lists.spdx.org/g/Spdx-tech/message/4027
Mute This Topic: https://lists.spdx.org/mt/81785860/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
