Remove string parsing requirement for select SPDX elements

[tsteenbe]

Several SPDX elements require string parsing to get the value specified by its creator see code examples below. In SPDX 3.0 we should simplify things and remove the need to do string parsing across element. This new ticket is a follow-up on discussions with @goneall @swinslow in https://github.com/spdx/spdx-spec/issues/412.

Document Creator

<CreationInfo>
    <creator>Person: Jane Doe () </creator>
    <creator>Organization: ExampleCodeInspect () </creator>
    <creator>Tool: LicenseFind-1.0 </creator>
</CreationInfo>

SPDX 3.0 proposal by @swinslow

"creators": [ {"type": "TOOL", "value": "LicenseFind-1.0"}, ... ]

Annotations

annotations:
- annotationDate: "2011-03-13T00:00:00Z"
   annotationType: "REVIEW"
   annotator: "Person: Suzanne Reviewer"
   comment: "Another example reviewer."
- annotationDate: "2010-01-29T18:30:22Z"
   annotationType: "OTHER"
   annotator: "Person: Jane Doe ()"
   comment: "Document level annotation"

SPDX 3.0 proposal by @tsteenbe:

annotations:
-  date: "2011-03-13T00:00:00Z"
   type: "REVIEW"
   annotator:
       - type: "PERSON"
          value: "Suzanne Reviewer"
          email: "[email protected]"
   comment: "Another example reviewer."
- date: "2010-01-29T18:30:22Z"
   type: "OTHER"
   annotator:
       - type: "PERSON"
          value: "Jane Doe"
   comment: "Document level annotation"

[zvr]

Any nested type is a pain because it has to be translated to flat tag-value pairs. So I assume you mean something like:

AnnotationDate: "2011-03-13T00:00:00Z"
AnnotationType: "REVIEW"
AnnotatorType: "PERSON"
AnnotatorValue: "Suzanne Reviewer"
AnnotatorEmail: "[email protected]"
AnnotationComment: "Another example reviewer."

(side note: why "Value" and not "Name"?)

Having simpler field names for nested content is obviously advantageous for JSON/YAML/RDF, but this would affect a lot of entries.

Should we start considering making the tag-value format obsolete in 3.0? (only half-joking)

[goneall]

Any nested type is a pain because it has to be translated to flat tag-value pairs.

I was thinking we could have it be a nested type for JSON, YAML, and XML but leave it as a parsed string for tag/value.

This may be the worst of both worlds for tools that support all of the serialization formats, but it would be more natural for tools that only support one.

why "Value" and not "Name"

Name would be a better term IMHO

[goneall]

This is resolved in 3.0 - closing