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
