-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Json examples #375
Json examples #375
Conversation
lets wait for the JSON-LD based JSON serialization before merging that. I think there are still two competing alternatives and we should see both before we commit in one direction. |
serialization/json/README.md
Outdated
after deserializing an Element instance. | ||
* **ElementSet** - an arbitrary set of Logical Values. | ||
* **Payload** - the result of serializing an ElementSet. | ||
* **SpdxDocument** - an SPDX Element containing metadata about a Payload. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
your definitions do not align with https://github.com/spdx/spdx-3-model/blob/main/model/Core/Classes/SpdxDocument.md. Instead of discussing it here buried down in a long file in some PR, maybe you can create issues and PRs for such statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do align, but the distinction between the logical model (which the diagram and model classes represent) and the physical model (which is represented by the payload <<interface>> and which we are just getting around to creating now) is apparently still not clear.
A physical File is a bunch of C code or anything else that goes in files. A physical Package is something that you install from a package manager. A physical SpdxDocument is the serialized value of one or more Elements.
- An SPDX File logical element as shown in the logical model doesn't contain C code, it describes the C code.
- An SPDX Package logical element cannot be installed from a package manager, it describes a package that can be installed.
- An SPDX SpdxDocument logical element does not contain serialized SPDX Element values, it describes serialized SpdxDocument bytes containing those values. There is only one SpdxDocument logical element that describes a dozen physical SpdxDocument byte strings that can go in physical files or be transmitted as a result of interface queries.
Because the logical model isn't a physical model, we had long discussions about how to represent a sequence of bytes on the logical model diagram and the logical model files. William came up with the name "Payload" for the physical SpdxDocument byte string to more clearly distinguish it from the logical SpdxDocument Element, but maybe that enables confusion instead. Would it be clearer if the Payload box were labeled "SpdxDocument byte sequence"?
Add payload example based on serialization team discussion |
Moving to 3.0 milestone - in the serialization meeting we decided to focus on JSON-LD for RC2 and the other serializations for 3.0. |
The current thinking is we just go with JSON-LD and not have a separate JSON format. Closing this PR. |
Add JSON examples for serialization use cases.
Create initial CBOR README.
Replaces #373 to address comments