Yes, the goal is common understanding rather than mere definition of terms.
I worded it poorly, but I do think it is important to understand the
distinction between modeling what we are trying to achieve by creating
SBOMs ("the real world") and modeling the bits used to represent
information transmitted between systems. Data languages such as XML, JSON,
Protobuf, and computer languages such as Java, C, Python have a fixed set
of primitives (integers, text strings, arrays, maps, etc). Without getting
hung up on terminology, there are two approaches to turning SBOM concepts
(the "object model") into characters on paper or bits on the wire ("data"):
1) do it separately for each data format (keyword:value, JSON, RDF, XML,
...), or
2) do it once by creating an "information model". The information model
then translates into various data formats the same way regardless of
whether the real-world domain is SBOMs or IoT device functions or
autonomous vehicles.
The takeaway is that Information models have Types and Fields only, and the
only relationships are "contain" and "reference". When you talk about
Objects and more specific kinds of relationships you are getting into the
SBOM domain.
Why go to the effort of creating an Information Model? It is the "single
source of truth" common across data formats.
As for Profile and Extension, I agree with Henk that restricting and
extending are different concepts, that both can be specified in one
document, and that if you call that document a Profile it isn't required to
have any extension content. A Profile document has restricting content,
an Extension document has extending content, but do we want a name for a
document that can have both types of content where each type is optional?
I hope there is no controversy over Namespace. A Package (in the UML
sense, not the SBOM sense) is a namespace applied to a collection of things
defined within the package.
Regards,
Dave
On Tue, Apr 13, 2021 at 8:51 AM Zavras, Alexios <[email protected]>
wrote:
> 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 (#4034): https://lists.spdx.org/g/Spdx-tech/message/4034
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]]
-=-=-=-=-=-=-=-=-=-=-=-
