Hi Dave,

 

The data type is a useful concept, but we may want to allow references within 
the serialization unit solely for the purpose of compactness.

 

That said – I need to think about the pros and cons a bit more and I’m 
interested in other’s views on the topic.

 

Regards,

Gary

 

From: David Kemp <[email protected]> 
Sent: Saturday, March 12, 2022 8:49 AM
To: Gary O'Neall <[email protected]>
Cc: Sean Barnum <[email protected]>; SPDX-list <[email protected]>
Subject: Re: [spdx-tech] Follow-up on non-Element classes

 

I agree with Gary and Sean that "references to these classes should be 
considered local to the serialization unit".

I would go farther and say there are no references to these "classes", local or 
otherwise.  In UML terms they are not classes at all, they are data types: 
https://www.omg.org/spec/UML/2.5.1/PDF Section 10.2: "DataTypes model Types 
whose instances are distinguished only by their value."  Data types are simple 
classifiers, as opposed to classes (Section 11.4) which are structured 
classifiers.

 

 A data type has no ID or primary key by which it can be referenced.  A 
multi-component datatype behaves like a primitive type (string) that can be 
split into components (e.g., comma-separated values).  "34.9821, 72.4913, red" 
is just a string when serialized but can be logically modeled as a {latitude, 
longitude, color} structure, where none of the individual components is a 
unique ID.  The only way to "reference" a primitive or structured data type is 
by supplying the entire value as the key.

Regardless of serialization, at the logical model level data type instances 
cannot be referenced.  I have no opinion on Gary's three approaches for 
serializing data types using RDF 
(https://www.w3.org/TR/rdf11-concepts/#section-Datatypes) as long as the 
value-only semantics is preserved across all serializations.

Dave

 

On Fri, Mar 11, 2022 at 9:44 PM Gary O'Neall <[email protected] 
<mailto:[email protected]> > wrote:

Hi Sean and SPDX Tech Team,

 

Following up on our call today, I think we uncovered an important issue on how 
to handle classes like ExternalReference, VerificationMethod and the recently 
discussed CreationInfo (which I would term “non-Element classes”) when viewed 
across different serialization units or documents.

 

I would like to make some progress on this issue and I can participate 
asynchronously through email.  I’ll be fully back online and re-joining the 
tech calls on the April 12th call.

 

I agree with Sean’s assertion on the call that references to these classes 
should be considered local to the serialization unit of the SBOM (a.k.a. 
Document).

 

For JSON, YAML, XML and Tag/Value this is pretty straight forward since (I 
believe) the only way to reference SPDX objects outside the document is using 
the ExternalMap which is restricted to Element classes.

 

For RDF, it gets a bit complicated since a Subject or Object can be a URI or 
Anonymous/Blank.  A URI can reference things external to the serialization unit.

 

I can think of 3 ways to handle this:

1.      Disallow use of URI’s types for references to these non-Element classes
2.      Allow for URI’s in addition to blank nodes but restrict the URI’s to 
being within the serialization unit / Document namespace
3.      Allow for any type of URI, but document that from an SPDX specification 
perspective they are only valid within the scope of the serialization unit

 

My current preference is #2 above.

 

There may be other options.

 

Let me know what you think.


Best regards,

Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: [email protected] <mailto:[email protected]> 

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is 
intended only for the person(s) or entity to which it is addressed and may 
contain confidential and/or privileged material. Any review, re-transmission, 
dissemination or other use of, or taking of any action in reliance upon this 
information by persons or entities other than the intended recipient is 
prohibited. If you received this in error, please contact the sender and 
destroy any copies of this information.

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4402): https://lists.spdx.org/g/Spdx-tech/message/4402
Mute This Topic: https://lists.spdx.org/mt/89725940/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to