Initial implementation

[JPEWdev]

The initial implementation of the SPDX go bindings

[mengzhuo]

I think we need to review the "import path" of this mod/package while user will confused by the version between spec and go module itself.

It's better to use multiple modules
Ref: https://go.dev/doc/modules/managing-source#multiple-module-source

spdx-v3 github.com/spdx/spdx-go-model/spdx-v3-0-1
spdx-v4 github.com/spdx/spdx-go-model/spdx-v4-0-0

While user can install by

go get github.com/spdx/spdx-go-model/[email protected]
go get github.com/spdx/spdx-go-model/spdx-v4-0-0@latest

or we can setup a prettier path like k8s project (k8s.io/api/core/v1) as for SPDX like spdx.dev/go/v3.0.1@latest

[JPEWdev]

I'm not sure we actually want to do multiple modules in this case. If we make multiple modules in the same repository, it looks like when we release, we would have to drop a tag for each version of SPDX spec in the repo. For example, to make a release, we would have to make tags:

spdx_v_3_0_1/v1.0.0
spdx_v_3_1_0/v1.0.0

etc.

(note: I couldn't figure out how to a module with - in the name)

Which will be a real pain given that we'll hopefully have several simultaneous SPDX versions in here, and also because all of the tags will always be dropped in the same location (because, all the code in this repo is effectively auto generated each release).

Given that the bindings for each release will "behave" pretty much the same for each SPDX version, I'm also not convinced that you'd want to allow users to pick different releases of the different bindings (e.g. v1.0.0 bindings for SPDX 3.0.1, v1.0.1 for SPDX 3.1.0, etc.). The binding code is only going to drastically change if we bump the version of shalc2code used to generate the bindings and I think we can manage that by A) fixing the version of shacl2code used (which I will do), and B) bumping the module major version and branching if necessary (e.g. when shacl2code changes the API).

[JPEWdev]

Also of note, I will make the bindings be named spdx_v3_0_1 instead of just v3_0_1 as that does remove the need for the import alias

[goneall]

I only reviewed the README, workflows and related artifacts - which all look good.

Looking for others with more GoLang expertise to review the generated code.

[viveksahu26]

@JPEWdev could you please give me a overview here about what you were looking a review for. Yesterday, in the meeting there were some glitch in the network from my side due to which I couldn't understand fully.

[JPEWdev]

@JPEWdev could you please give me a overview here about what you were looking a review for. Yesterday, in the meeting there were some glitch in the network from my side due to which I couldn't understand fully.

I'm not a go expert, this is the first go program I've ever written, so what I would like is for some people knowledgeable in go to look over the code (in particular the usage in the examples) and make sure it's reasonable from a go user perspective

[viveksahu26]

Use append() for Slices Instead of Custom Methods.

• Instead of ci.CreatedBy().AppendObj(p), use ci.CreatedBy = append(ci.CreatedBy, p).

The built-in append function is the idiomatic way to work with slices in Go.

[JPEWdev]

The reason for this is two fold:

1. it allows validation of the assigned value immediately when it's appended. This reduces errors when using the bindings as you can determine exaclty where a bad value was assigned, instead of having to find out later when all context is lost.

2. In the particular case where a property references an object, either an object or a string IRI can be assigned, so there is also an AppendIRI() method; both of these are convenience shortcuts to the Append() method which requires a properly types Ref object

[viveksahu26]

Avoid Unnecessary Getters

• Instead of using p.ID().Set(value), use p.SetID(value),
• Similarly, p.Name().Set(value), use p.SetName(value)
• Similarly, ci.SpecVersion().Set(value), use ci.SetSpecVersion(value)
• and, ci.Created().Set(valu), use ci.SetCreated(value)

Something like this: https://go.dev/play/p/tREj7_5eQFN

You can checkout these resources to understand more about getter and setter in go:

• https://stackoverflow.com/questions/11810218/how-to-set-and-get-fields-in-structs-method/11842484#11842484
• https://softwareengineering.stackexchange.com/questions/278807/does-go-implicitly-discourage-getters-and-setters-and-encourage-direct-member-ac

[JPEWdev]

The reason for this is because all of this code is auto-generated, so having a common "string property" class that can be reused all the places where a class has a string property is much easier to generate code for than (effectively) open coding it everywhere. I do appreciate this is not "the go way", so I'll look into it though

[viveksahu26]

Similarly here: Avoid Unnecessary Getter/Setter Chaining:

Refractor it to:

email.SetExternalIdentifierType(spdx_v3_0_1.ExternalIdentifierTypeEmail)
email.SetIdentifier("[email protected]")

[viveksahu26]

Similarly avoid AppendObj and simply refractor it to:

p.ExternalIdentifiers = append(p.ExternalIdentifiers, email)

[viveksahu26]

If this, if it is internally appending an objects as name suggest, AddObject, then instead of that use a simple append().
Refractor it as:

objset.Objects = append(objset.Objects, p, doc)

[JPEWdev]

objset does indexing on objects added to it to make lookup faster, so append() cannot be used

[viveksahu26]

Similarly these one, as per above suggested to avoid getter.

• Instead of doc.CreationInfo.Set(value), use doc.SetCreationInfo(ci), and
• doc.ID().Set(value), by doc.SetID(value)

Refractor with:

func (d *SpdxDocument) SetCreationInfo(ci CreationInfo) {
    d.CreationInfo = ci
}

and

func (d *SpdxDocument) SetID(id string) {
    d.SetID = id
}

[JPEWdev]

It can't be that simple, due to validation requirements (as stated, an important point of these bindings is to fail as early as possible if a bad value is assigned)

CreationInfo can be either a Object or a String IRI reference, so maybe something like:

doc.SetCreationInfoObj(value)
doc.SetCreationInfoIRI("http://foo.bar/creationinfo")
doc.SetCreationInfo(creationInfoRef)

would be OK?

[viveksahu26]

Ensures test execution stops immediately when a failure occurs.

• t.Error(err) will continue test even after errors
• whereas, t.Fatal(err), will stops execution test upon failure.

So, refractor this too:

if err != nil {
    t.Fatal(err) // Terminates test immediately
}

[JPEWdev]

Got it, thanks.

[kzantow]

I’ve written and re-written this a few times now, so please accept my apologies for the delay and also for the length of this comment. And, before continuing, I want to sincerely express my gratitude for your effort here to get SPDX 3 support implemented for Go — it’s not a trivial task — in fact, it may be one of the more challenging languages!

I think the easiest way to present this is to start at the end by generating one of the Go data models that I think works best for tools-golang. As a maintainer, I hope to provide a way for users to use the SPDX 3 format with minimal friction by using Go language features as best we can to help enforce and/or guide correct usage. This is especially challenging due to the lack of inheritance in the language and the reliance on inheritance in the spec. Rather than give exhaustive feedback on this PR, I think it’s easier to show what works about this updated model and explain why I’ve made some of the decisions. Generally, this approach is:

• struct-first — users almost always reference concrete structs, not interfaces
• inheritance through embedding — this leans into properties of embedding, especially: pointer references to embedded structs
• utility functions — some purposeful utility functions and types are provided to handle the bulk of the type assertions

To start the discussion, I’ve re-written the example using this struct-first data model:

// Create a new Person
p := &spdx.Person{Agent: spdx.Agent{Element: spdx.Element{
	// Set the unique identifier (IRI) for the person
	ID: "http://spdx.org/spdxdocs/person-example",
	// Set the name for the person
	Name: "Joshua",
	// Add an e-mail address for the person
	ExternalIdentifiers: spdx.ExternalIdentifierList{
		&spdx.ExternalIdentifier{
			ExternalIdentifierType: spdx.ExternalIdentifierType_Email,
			Identifier: "[email protected]",
		},
	},
}}}
ci := &spdx.CreationInfo{
	SpecVersion: "3.0.1",
	Created:     time.Now(),
	CreatedBys:  spdx.AgentList{p},
}
// set the circular reference: the creation info as the creation info of the Person
p.CreationInfo = ci

// Create a SPDX Document object (can use direct property access)
doc := &spdx.SpdxDocument{}
doc.ID = “http://spdx.org/spdxdocs/doc-example",
doc.CreationInfo = ci,

What’s different and why?

Type safety

Types are enforced more appropriately: since interfaces in Go are implicit, these can have problems constraining in certain situations and make some type assertions impossible. The biggest spots this is an issue are where inheritance-only interfaces get generated, for example:

type Agent interface {
	Element
}

And more problematic top-level SHACLObjects:

type PresenceType interface {
	SHACLObject
}

… this means anything with a type constraint using one of these interfaces will also allow ANY type that satisfies the supertype’s interface. In other words, I can set any Element or subtype where Agent is declared and any Element or subtype will satisfy a type assertion to Agent; e.g.in this PR, the following is allowed:

swp := spdx_v3_0_1.MakeSoftwarePackage()
ci.CreatedBy().AppendObj(swp) // allowed

agent := swp.(spdx.Agent) // allowed

The “struct-first” approach defines interfaces based on the structs, so regardless of extra properties being added from the SHACL model, the interface restricts to correct subtypes; e.g. this is a compilation error:

swp := &spdx.SoftwarePackage{}
ci.CreatedBys = append(ci.CreatedBys, swp) // not allowed

In this PR, a user just references strings for the constants, as in the example, email.ExternalIdentifierType().Set(spdx.ExternalIdentifierTypeEmail): spdx.ExternalIdentifierTypeEmail is a string, so there’s virtually no type safety for: email.ExternalIdentifierType().Set("anything”). We can treat these as “enum”-like concrete structs in a manner similar to how Gary has used enums in Java (for example, the PresenceType), to make them about as close as we can get to typed enums in Go, for example this is a compilation error:

&spdx.ExternalIdentifier{
	ExternalIdentifierType: spdx.PresenceType_Yes,
}

Validation

In this PR, since each setter operation checks values for validity, a user must error check every operation like:

if err := externalIdentifier.ExternalIdentifierType.Set(“asdf”); err != nil {
  return err
}

This gets fairly cumbersome, which is why you don’t find a lot of Go interfaces where setters return errors. If the code fails-fast — which this pattern promotes — implementations could easily end up providing one error at a time to a user and the user ends up playing whack-a-mole rather than knowing up front all the things they need to fix. In this PR, there are other validations that happen at other times, too, so I would opt for a single “validate” call to check an entire object graph for validity without setters returning errors. The updated model avoids setter validation altogether by allowing direct property access.

Idiomatic Go

Most typical data format libraries in Go use concrete structs with only the properties that represent the data values, rather than interfaces containing additional metadata about the type. In this PR, it is not really possible to instantiate these structs directly — they require setup using unexported functions, so these must be created using constructor functions and in these construction functions there is work is happening setting up property constraints and metadata, like this:

validators = append(validators,
	EnumValidator{[]string{
		"https://spdx.org/rdf/3.0.1/terms/Dataset/DatasetType/audio",
		…
		"https://spdx.org/rdf/3.0.1/terms/Dataset/DatasetType/video",
	}})
o.datasetDatasetType = NewListProperty[string]("datasetDatasetType", validators, decodeValidators)

While using interfaces is quite common, it’s rare for data objects to be implemented with interfaces. For example, if I have code that only deals with SoftwarePackages, and I don’t ever need to know about AIAiPackage values, I can write a function in terms of spdx.SoftwarePackage, and have familiar struct-like access to the fields rather than nearly everything accessed through a wrapper type: p.CreationInfo vs p.CreationInfo().Get(). The indirection using ref types works, but it’s uncommon to see a pattern like this in Go.

Having concrete structs also aligns more closely with tools-golang, which will make transition to v3 easier for existing users of the library. And in tools-golang, at least, version migration would work best with a struct-first approach, I’ll mention because I feel strongly that version migrations are an essential part of the library’s purpose. If everything is specified in terms of interfaces this makes things a bit more loose and certainly isn’t compatible with the migration mechanism today.

Utilities

The last, and maybe the most important thing for working with documents, is that I’ve included some utility methods and specialized collection types. These collections are simply typed slices, so they are easily able to be iterated over, and modified using typical go code, such as: for _, val := range p.SomeCollection { and p.SomeCollection = append(p.SomeCollection, values…).

The example usage in this PR is only creating the bare minimum required for a valid document and serializing it. What isn’t shown is working with existing documents. This is where having such a flexible structure based on inheritance can become quite tedious to work with in Go. I’d proffer that most users of SPDX are performing one type of task at time: operating on all the files or packages or some other specific set of types.

Let’s take a basic example: identify all the CONTAINS relationships from files to packages. Since the RootElements type is an Element list, it’s no help figuring any of this out, we’re left iterating through everything and performing a bunch of checks; something like this:

filesToPackages := map[spdx.SoftwareFile][]spdx.SoftwarePackage{}
for _, e := range doc.RootElement().Get() {
	if !e.IsObj() {
		continue
	}
	sbom, _ := e.GetObj().(spdx.SoftwareSbom)
	if sbom == nil {
		continue
	}
	for _, v := range sbom.RootElement().Get() {
		if !v.IsObj() {
			continue
		}
		relationship, _ := v.GetObj().(spdx.Relationship)
		if relationship == nil {
			continue
		}
		if relationship.RelationshipType().Get() != spdx.RelationshipTypeContains {
			continue
		}
		if !relationship.From().IsObj() {
			continue
		}
		fi, _ := relationship.From().Get().(spdx.SoftwareFile)
		if fi == nil {
			continue
		}
		for _, to := range relationship.To().Get() {
			if !to.IsObj() {
				continue
			}
			swp, _ := to.GetObj().(spdx.SoftwareFile)
			if swp == nil {
				continue
			}
			filesToPackages[f] = append(filesToPackages[f], p)
		}
	}
}

By generating iterator functions for each subtype with a specialized collection, this becomes very easy: any ElementList has .SoftwarePackageIter() for example, and this is pervasive throughout the model, so the aforementioned task of finding packages with contains relationships to files in this model is:

filesToPackages := map[*spdx.SoftwareFile][]*spdx.SoftwarePackage{}
for _, v := range sbom.RootElements.RelationshipIter() {
	if v.RelationshipType != spdx.RelationshipType_Contains {
		continue
	}
	spdx.As(v.From, func(f *spdx.SoftwareFile) {
		for _, p := range v.Tos.SoftwarePackageIter() {
			filesToPackages[f] = append(filesToPackages[f], p)
		}
	})
}

I also didn't want to gloss over the lack of ref types: the updated model generates an external IRI type that implements all interfaces, so it can be used in place of any reference type, e.g.:

doc.RootElements = append(doc.RootElements, spdx.NewExternalIRI("asdf"))

Last thoughts

There are a number of things mentioned here that are not exclusive to the data model I’ve presented — some things could be applied to the data model in this PR to solve some of the issues like type constraints and enum values, but overall it will be difficult to use this data model in tools-golang without some changes.

I also didn’t touch on an important detail: how the data model gets serialized to JSON-LD. I’m much less concerned about this detail aside from feeling strongly that the serialization and validation metadata should be stored separately from the data to avoid unnecessary memory usage. I believe the idiomatic solution would involve using Go struct tags to specify field mapping information, much like the Go standard library uses them to specify field mapping information for plain JSON. Reflection in Go is excellent: it is performant and ideal for this type of thing, which is why it’s used throughout the standard lib for similar purposes.

The updated data model, including validation code comes in around 6,000 lines whereas this PR is around 18,000. This isn’t a huge problem but since a user will have to ship copies of every single version of this model including every patch version, there could end up being quite a lot of code that builds up, increasing compile times, binary sizes, etc.; so smaller is better here. This is really just a nice-to-have.

To touch on the package naming and versioning from one of the comments: since this library will have every data model, rather than updating a single data model over time, I don’t think using a v3 type Go versioning scheme will help much of anything: a user does not need to import this library multiple times, since it will already contain every model they need. I would almost certainly use a v0.x version to start with and only move to a post-v1 scheme after this model has been proven to work and is in use. I, personally, would organize the code with these directories: top-level v3, containing subdirectory: v3_0_1 with a matching package name of v3_0_1 but it could be named spdx_v3_0_1 or anything, really — if this is used in tools-golang, these models will be re-exported under a package named spdx, so a user would reference spdx. and not really have to deal with the version numbers, otherwise it’s a bit of a pain to bump the imported package every single patch release — it requires code changes to every file that imports it!

It is my hope we can have a model here that works well for tools-golang, but I am a little confused why the original work on this does not seem to have influenced the model in this PR. Regardless, I think it’s important to address some of the points I’ve raised, and I have some shacl2code changes to generate the model I’ve presented, if this is something we can work towards.

[nishakm]

I'm adding an implementation example for this particular implementation as of Feb 5 2025 (in case this gets lost in the comments). I haven't looked at @kzantow's comments yet. This is specifically for the protobom folks @puerco.
I've tried to recreate the very basic SPDX 3 document from example1

package main                                                                                                                                                                                  
                                                                                                                                                                                              
import (                                                                                                                                                                                      
        "encoding/json"                                                                                                                                                                       
        "fmt"                                                                                                                                                                                 
        "os"                                                                                                                                                                                  
        spdx "spdx3/pkg/spdx"                                                                                                                                                                 
        "time"                                                                                                                                                                                
)                                                                                                                                                                                             
                                                                                                                                                                                              
func main() {                                                                                                                                                                                 
        // Write doc                                                                                                                                                                          
        WriteToStdout()                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                              
}                                        

func MakeDoc() spdx.SHACLObjectSet {
        
        objset := spdx.NewSHACLObjectSet()

        p := spdx.MakePerson()
        // ought to be generated
        p.ID().Set("https://swinslow.net/spdx-examples/example1/hello-v3-specv3/SPDXRef-gnrtd0")
        p.Name().Set("Steve Winslow")
        // This is how you create a reference
        p_ref := spdx.MakeObjectRef[spdx.Agent](p)
        objset.AddObject(p)

        ci := spdx.MakeCreationInfo()
        // ought to be set depending on pkg used
        ci.SpecVersion().Set("3.0.1")

        ci.CreatedBy().Append(p_ref)
        ci.Created().Set(time.Now().UTC())

        // you can set CreationInfo for an Agent
        p.CreationInfo().Set(spdx.MakeObjectRef(ci))

        email := spdx.MakeExternalIdentifier()
        email.ExternalIdentifierType().Set(spdx.ExternalIdentifierTypeEmail)
        email.Identifier().Set("[email protected]")

        p.ExternalIdentifier().Append(spdx.MakeObjectRef(email))

        doc := spdx.MakeSpdxDocument()
        // ought to be generated
        doc.ID().Set("https://swinslow.net/spdx-examples/example1/hello-v3-specv3/document0")
        doc.CreationInfo().Set(spdx.MakeObjectRef(ci))

        objset.AddObject(doc)
        return objset

}

func WriteToStdout() {                                                                                                                                                                        
        // not a document but a SHACLObjectSet                                                                                                                                                
        objset := MakeDoc()                                                                                                                                                                   
        // write to stdout                                                                                                                                                                    
        encoder := json.NewEncoder(os.Stdout)                                                                                                                                                 
        if err := objset.Encode(encoder); err != nil {                                                                                                                                        
                fmt.Println(err)                                                                                                                                                              
                os.Exit(1)                                                                                                                                                                    
        }                                                                                                                                                                                     
}

This should produce the following:

$ go run main.go | jq
{
  "@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld",
  "@graph": [
    {
      "@id": "_:CreationInfo0",
      "created": "2025-02-05T15:58:57Z",
      "createdBy": [
        "https://swinslow.net/spdx-examples/example1/hello-v3-specv3/SPDXRef-gnrtd0"
      ],
      "specVersion": "3.0.1",
      "type": "CreationInfo"
    },
    {
      "creationInfo": "_:CreationInfo0",
      "externalIdentifier": [
        {
          "externalIdentifierType": "email",
          "identifier": "[email protected]",
          "type": "ExternalIdentifier"
        }
      ],
      "name": "Steve Winslow",
      "spdxId": "https://swinslow.net/spdx-examples/example1/hello-v3-specv3/SPDXRef-gnrtd0",
      "type": "Person"
    },
    {
      "creationInfo": "_:CreationInfo0",
      "spdxId": "https://swinslow.net/spdx-examples/example1/hello-v3-specv3/document0",
      "type": "SpdxDocument"
    }
  ]
}

I'm not sure how to test ingestion and marshaling yet:

func ReadFromStdin() {
        // read from stdin
        decoder := json.NewDecoder(os.Stdin)
        objset := spdx.NewSHACLObjectSet()
        if err := objset.Decode(decoder); err != nil {
                fmt.Println(err)
                os.Exit(1)
        }
        fmt.Println(objset)
}

$ go run main.go < serialize.json 
&{[0xc00019a000 0xc0001da008 0xc0001ad608] map[]}

[nishakm]

@kzantow @JPEWdev Last I looked at this, the issues with Go boil down to the following:

1. Structs first means one can assign any data type to any property as long as the underlying type is the same. Hence we have to use interfaces to validate if the type is correct.
2. Types in SHACL go deeper than the SPDX data model. For example, "date" is not a string but a "DateType" which conforms to a specific pattern. A further complication in SHACL: "DateType" can either be a string or an IRI, so a user should be able to assign both.

In this implementation, there is a SHACLObject struct with its own properties that get implemented. However, it doesn't follow the typical "implement the interface, then implement the struct" pattern that is used in Element for example. That's probably why you can do:

swp := spdx_v3_0_1.MakeSoftwarePackage()
ci.CreatedBy().AppendObj(swp) // allowed

agent := swp.(spdx.Agent) // allowed

I think implementing the meta SHACLObject and its properties makes the code amenable to be generated from the single shacl .ttl file without errors.

Also, the reason I had suggested creating a new repository to host the generated code is so that helper functions and helper libraries can be created separate from this. Users will not have to look at this underlying mess and instead have cleaner functions to use in their applications.

[JPEWdev]

@kzantow @JPEWdev Last I looked at this, the issues with Go boil down to the following:

1. Structs first means one can assign any data type to any property as long as the underlying type is the same. Hence we have to use interfaces to validate if the type is correct.

2. Types in SHACL go deeper than the SPDX data model. For example, "date" is not a string but a "DateType" which conforms to a specific pattern. A further complication in SHACL: "DateType" can either be a string or an IRI, so a user should be able to assign both.

In this implementation, there is a SHACLObject struct with its own properties that get implemented. However, it doesn't follow the typical "implement the interface, then implement the struct" pattern that is used in Element for example. That's probably why you can do:

swp := spdx_v3_0_1.MakeSoftwarePackage()
ci.CreatedBy().AppendObj(swp) // allowed

agent := swp.(spdx.Agent) // allowed

I think implementing the meta SHACLObject and its properties makes the code amenable to be generated from the single shacl .ttl file without errors.

The SHACLObject exists so that object in the document can be added to the SHACLObjectSet, which only deals with SHACLObjects

Also, the reason I had suggested creating a new repository to host the generated code is so that helper functions and helper libraries can be created separate from this. Users will not have to look at this underlying mess and instead have cleaner functions to use in their applications.

[JPEWdev]

swp := spdx_v3_0_1.MakeSoftwarePackage()
ci.CreatedBy().AppendObj(swp) // allowed

agent := swp.(spdx.Agent) // allowed

This is fixed by JPEWdev/shacl2code#43

[lumjjb]

Also, the reason I had suggested creating a new repository to host the generated code is so that helper functions and helper libraries can be created separate from this. Users will not have to look at this underlying mess and instead have cleaner functions to use in their applications.

I think that this sounds reasonable as a framing.. IIUC that project would be a SHACL focused minimal use, and that would mainly be the validation and use of UML.

The tools-golang repo would be focused on having a good user experience of the spdx 3.0 model. Similar to what we do for the 2.x models, usage of 2.x models are based on the "common struct" and users need not need to be aware of the internals for whether it is a 2.1 or 2.2 model.

My only concern is creating a split of mix use of the two libraries which can result in some really weird use behavior.

struct-first — users almost always reference concrete structs, not interfaces

I agree very much with this as the pattern for golang. However another way of perhaps allowing a struct-first declarative structure is via using the NewX pattern. Where we can have spdx.NewPerson(&spdx.PersonDefinition{...}).

inheritance through embedding — this leans into properties of embedding, especially: pointer references to embedded structs

One thought i was exploring here was trying to map it to more common golang definitions that follow inheritance type patterns. Most commonly the "inheritance" style types defined in golang mirror the OR type (which is analogous with the oneof keyword in protobuf.

Thus a struct of an agent could be reflected that way:

type AgentType struct {
    Person *Person
    Organization *Organization
    SoftwareAgent *SoftwareAgent
    Agent *Agent
}

This could be used in addition to the AsAgent() and Type() call which could allow the user to extract an agent instance for programmatic comparison...

a1 := AgentType{&Person{...}}
a2 := AgentType{&Organization{...}}

if a1.Type() == "Person" {
    a1.Person.Name = "xyz"
   // ...
}

sameName := a1.AsAgent().Name == a1.AsAgent().Name
// ...

[JPEWdev]

I don't really care too much if another approach should be taken; the problem I have is that I don't really have time to write a brand new golang implementation in shacl2code at the moment; is there someone who would be willing to take that on? I can certainly provide advice on what needs to be done to get the generation integrated into shacl2code properly (or maybe the existing golang implementation I have is sufficient to demonstrate that).

[lumjjb]

I think the work you've done here is plenty @JPEWdev ! And I think that is a good start that can build upon. Based on @kzantow 's ability to create a variant in spdx/tools-golang#249, it sounds like the generation code is in a good state that is ready for others to add contributions?

Would it be fair to say that 3.0 is still early in adoption, and so we will have the opportunity to iterate. Given the several concerns brought up in this PR, perhaps could merge and released as a 0.x version so that the messaging is that there will likely be changes to the interface in the future? That way folks that are blocked can start using it (with early adopter usability caveats).