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/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 (#4023): https://lists.spdx.org/g/Spdx-tech/message/4023
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]]
-=-=-=-=-=-=-=-=-=-=-=-
