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/spdx-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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4022): https://lists.spdx.org/g/Spdx-tech/message/4022 Mute This Topic: https://lists.spdx.org/mt/81780695/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
