Serialization: Creation Information

[davaya]

Some time ago we moved creation-related properties from Element to the CreationInformation class because 1) they are related in purpose and 2) it makes Element easier on the eyes. But that raises the question of default values - if Element has a creationInfo property of type CreationInformation, then its value is treated as a single unit, not five or six separate property values. That won't work because the requirement is for each property to have an individual default value that doesn't need to be sent even if another property is not defaulted.

Two potential solutions:

1. Move the individual creation-related properties back into Element
2. Define a "macro" modeling notation that substitutes one value for another, e.g.:

        Element
+ SPDXID: IRI
+ name: String [0..1]
+ summary: String [0..1]
+ description: String [0..1]
+ comment: String [0..1]
#include CreationInformation
+ verifiedUsing: IntegrityMethod [0..1]
 ...

where the #include macro substitutes the group of properties called CreationInformation into Element, and there is no actual CreationInformation class.

If we did that, I'd shorten Element even more by defining a DescriptiveInformation macro with the summary, description, and comment properties.

Pros of #1: doesn't need any new modeling conventions or tooling support
Cons of #1: Element is bloated
Pros of #2: it's cool
Cons of #2: needs work to invent, macro properties must be de-duplicated (e.g. creationComment)

[goneall]

That won't work because the requirement is for each property to have an individual default value that doesn't need to be sent even if another property is not defaulted.

I'm of the opinion that individual default values do not make sense. One of the main purposes of a default value is to not repeat the same information for Elements created at the same time from the same creator etc - in which case you would have all the same CreationInfo defaults.

This opens up another solution where you have a default CreationInfo and if you would want to have a different value for any of the CreationInfo fields, you'd just create a separate CreationInfo just for that element.

[iamwillbar]

Capturing what I said during today's tech meeting:

At a logical level, every element has a creation information, with all the properties containing their final value.

At a serialization level, a serializer can do any optimization it desires (including none), if once deserialized every element has a creation information, with all the properties containing their final value (i.e. it complies with the logical model).

For example, a serializer may optimize for space by storing duplicative creation information once and using a pointer in the element. On deserialization it would resolve the pointer and attach the creation information to the element (it could retain the pointer if it wanted to minimize differences when serializing that content back out).

Another example, a serializer that used hierarchies may optimize for space by supporting per-property inheritance by storing common values in the highest level of the hierarchy. On deserialization (or even when accessed) it would walk the hierarchy to retrieve the value of any property in the creation information.

[davaya]

At the logical level, every element has one creationInfo property of type CreationInformation.

At a serialization level, a serializer can do any optimization it desires (including none), if once deserialized every element has a creation information, with all the properties containing their final value (i.e. it complies with the logical model).

True, but we are going to define serialization in a way that supports interworking. "A serializer" doesn't mean whatever a developer chooses, it means whatever SPDX documents as the standard. Whatever we document must support serialization of a single element, and the optimization algorithm for serializing multiple elements must be defined.

As I noted in https://github.com/davaya/spdx-3-model/tree/serialization/serialization, the conceptually simplest serialization would just concatenate the individual elements and then compress them (with gzip or whatever). When we define a serialized format it shouldn't be conceptually harder to understand than that.

[davaya]

As William said, the logical model defines element properties, one of which is creationInfo. Every serialization must preserve the logical value of every element. The approach to satisfying that requirement in the most effective manner will be discussed by the Serialization (Thursday) and Canonicalization (Friday) teams

[goneall]

I believe this has now been agreed to and resolved for JSON-LD.

Closing this issue.