Resolve two issues related to ExternalDocumentRef

[KAWAHARA-souta]

ExternalDocumentRef.DocumentRefID does not perform required prefix processing because it is a string, although comments states like below.

spdx/v2/v2_3/document.go (L.19~23):

type ExternalDocumentRef struct {
	// DocumentRefID is the ID string defined in the start of the
	// reference. It should _not_ contain the "DocumentRef-" part
	// of the mandatory ID string.
	DocumentRefID string `json:"externalDocumentId"`

I've fixed it and also fixed related issue. (#267, #268)

[kzantow]

I do not think this change is correct. Adding an element ID reference to the document ID specifier is not what we should do.

It's a little unclear to me whether the JSON external document reference should include DocumentRef- or not -- please note that the JSON format has some oddities that don't always match the TagValue and other formats, but I think it probably should based on the examples in the spec.

I think the correct change to make here is not to use the common.DocElementID, but instead create a new typed string of type common.DocumentID string, which has the behavior of prepending and removing the DocumentRef-, this field which is used in the External Reference objects, as well as the common.DocElementID for consistency. This would end up being less of a breaking change, too, since initializers using strings would continue to work.

[kzantow]

common.DocElementID is the combination of 3 things: external document reference, element reference, and special ID. The DocumentRefID is supposed to be only an ID to reference the external document within this document, this should not include ElementID or special references, this is why it is a string. It is a little unclear if this should include DocumentRef-. If you look at the JSON schema, it makes no reference to this except in the license section, which indicates DocumentRef- is only used in an element ID reference when you are referring to an external document using the docrefIdString, which I think is supposed to match the value here: DocumentRef-[docrefIdString]:.

[KAWAHARA-souta]

Thanks @kzantow ,

I agree that creating a new typed string of type common.DocumentID string.
I will modify the PR accordingly. After that, Could you review it again once I complete the changes?

I also have a question regarding the creation of type common.DocumentID string.

Currently, DocElementID is structured as follows:

type DocElementID struct {
	DocumentRefID string
	ElementRefID  ElementID
	SpecialID     string
}

Would it be OK to change the type of DocElementID.DocumentRefID to the newly created common.DocumentID ?
Additionally, like my commit ea4f07f , would it be OK to make it possible to output a DocElementID as a simple Document ID even when it only has DocumentRefID ?

My main concern is that the type of items specified in Relationship is common.DocElementID:

type Relationship struct {
	// 11.1: Relationship
	// Cardinality: optional, one or more; one per Relationship
	//              one mandatory for SPDX Document with multiple packages
	// RefA and RefB are first and second item
	// Relationship is type from 11.1.1
	RefA         common.DocElementID `json:"spdxElementId"`
	RefB         common.DocElementID `json:"relatedSpdxElement"`

My main intention is to enable the creation of Relationships to Documents (including ExternalDocumentRefs)