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