Thanks for these, David and Henk. I propose that we do not spend time try to formalize what we mean by using terms like Object, Field, and Type -- I only used these words in my email to talk about the interaction between profiles.
Based on the call of last week, it seems we have more pressing issues to define stuff like Model, Profile, Extension, and Namespace. At least the discussion (and consensus?) was to use these in a way that was different to (at least) my understanding till now. Hopefully I the only one misunderstanding them 😊. I propose we take the first few minutes on the call today to go through the terms; not for strict definitions, but for bringing the general understanding on the same page. -- zvr -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Henk Birkholz Sent: Monday, 12 April, 2021 23:42 To: David Kemp <[email protected]>; Zavras, Alexios <[email protected]> Cc: [email protected] Subject: Re: [spdx-tech] interactions between profiles Hi Dave, hi Alexios, On the one hand, I really think that it does not hurt to separate the concepts of constraining a model (i.e., profile) and adding to a model (i.e., extension), explicitly. RFC7925 is a good example for a profile. Both a profile definition and an extension definition can be included in the same specification. Separating them explicitly just makes it simpler for implementers to quickly grasp what goes where. I have to point out that I am quite reluctant to agree with the premise that is "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)." Maybe I am reading it wrong. On the other hand, I also really think that the IP analogy does not work very well here. My 2c: 1.) TCP neither creates nor modifies IP 2.) The IP comes with an IANA registry for "the next level protocol" (RFC790). That list of registered protocols is "mutable" (e.g. entries can be added or deprecated). Packets that conform with IP standards can express various states or configurations, but that does not render the protocols themselves "mutable". I am having a really hard time to relate the quality "mutable" with IP, tbh. 3.) TCP is not a profile/extension/augment of IP. TCP is simply a "next level protocol" that specifies PDUs (segments) that can be nested in IP PDUs (packets), as it literally works on a different layer of protocol stacks. Another example would be QUIC that is nested in UDP. Viele Grüße, Henk On 12.04.21 22:41, David Kemp wrote: > Hi Alexios, > > Regarding the general meaning of Object, Field and Type: in UML a > datatype is a simple classifier ("DataType differs from Class in that > instances of a DataType are identified only by their value. All > instances of a DataType with the same value are considered to be equal > instances.") and a Class is a structured classifier ("to specify a > classification of objects and to specify the Features that > characterize the structure and behavior of those objects.") > > Objects are used when modeling the real world, but types are used when > modeling data. Data instances are values, data types have neither > behavior nor inheritance, and the only relationships between data > types are "contain" and "reference". Documents contain their own > content and can link to other documents. The PDF version of the SPDX > spec knows nothing about SPDX, it just knows about paragraphs, fonts, > tables, etc. Data instances are not objects, and a language such as > JSON Schema defines only Types and Fields. Of course Objects can be > serialized as data, but their semantics, relationships and behavior > are not relevant at the data layer, they only become relevant when > interpreted by applications such as an SBOM scanner or the TCP driver in a > network stack. > > RFC 4775 discusses extensibility: > > "An extension is often likely to make use of additional values added > to an existing IANA registry (in many cases, simply by adding a new > "TLV" (type-length-value) field)." > > IPv4 has a "Protocol" field, an 8 bit value used to designate the > format of the protocol header contained in the IP header. > > So to get back to our discussion, is defining TCP "creating" or > "modifying" IP? Is IP mutable or not? If TCP is a profile of IP; > does it define something new or restrict what already exists? > > My answers are: > 1) TCP does create something new that isn't defined in IP > 2) IP is not "mutable", it is extensible through the use of extension > points such as the protocol enumeration, Adding fields to an > enumeration (including the enumerated values in an array or map > structure) is a special case that should be distinguished from the > general mutability of deleting, modifying or inserting fields in > instances without defining them in the Type. > 3) TCP is a profile of IP in the same sense that Bluetooth profiles > extend the base spec, not restrict it to a subset of what is defined > in the base spec. > > If the word "profile" is a Venn diagram sticking point, then perhaps > "extension" would be a better word to use when defining new things > that fit into the base. OpenC2 uses "profile" in the Bluetooth sense > of defining new types as well as adding constraints to types defined > in the base. Tightening constraints on base types (going from > optional to > required) in a profile is fine, relaxing them (going from required to > optional) is verboten. > > Dave > > > On Thu, Apr 1, 2021 at 11:55 AM Alexios Zavras > <[email protected] <mailto:[email protected]>> 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.____ > > __ __ > > 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?____ > > __ __ > > 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 (#4033): https://lists.spdx.org/g/Spdx-tech/message/4033 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]] -=-=-=-=-=-=-=-=-=-=-=-
