Greetings all,
Our next serialization meeting is tomorrow (Thursday) at 8AM Pacific Time (3PM GMT). We will be continuing the discussion from the tech call on how we specify the handling of IDs for the serialized format (pull request 622). To avoid re-opening old issues unless absolutely needed, below is a list of previous decisions on the handling of ID based on reviewing the notes (primarily based on the meeting minutes from 2023-07-21 <https://github.com/spdx/meetings/blob/main/serialisation/2023-07-21.md> , 2023-08-01 <https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-01.md> , 2023-08-08 <https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-08.md> , 2023-8-10 <https://github.com/spdx/meetings/blob/main/serialisation/2023-08-10.md> ): * Every class will have an ID. This includes both Element and non-Element classes (e.g. CreationInfo, Hash). * Elements are required to have an ID which is a URI that can be shared across serializations (Note: Sean may not have agreed to this decision) * Serializations are allowed to use anonymous ID's / blank nodes (e.g. they can inline the checksum class in JSON-LD) for non-Element classes however, when deserializing they must be made unique within the internal model representation (e.g. Skolomized <https://en.wikipedia.org/wiki/Skolem_normal_form> ). * CreationInfo will use anonymous / blank node ID's in JSON-LD as the compaction approach Additional references: * Duplication of creation information was discussed on 2023-05-16 <https://github.com/spdx/meetings/blob/main/tech/2023/2023-05-16.md> and 2023-06-27 <https://github.com/spdx/meetings/blob/main/tech/2023/2023-06-27.md> * Issue comment <https://github.com/spdx/spdx-3-model/issues/357#issuecomment-1656482951> indicating we agreed to use anonymous nodes in JSON-LD for creation info * JSON example with significant comment / discussions on creation info - pull request 376 <https://github.com/spdx/spdx-3-model/pull/376> * Open issue describing various compaction algorithms If anyone believe we did not make the above decisions, please raise this before we dive into solutions - preferably via email before the meeting. I've made a couple of conclusions (or perhaps assumptions) based on the above - quite interested if others have come to different conclusions: * I don't recall if this was explicitly discussed, but based on the fact we have in the model the SPDX ID on Element and not on any other class, I believe Element IDs need to be treated differently than any other IDs during serialization / deserialization (note that I did not say in the model - just in serialization / deserialization) - for example - restrict the node type to be a URI type and not allow blank nodes. This would not be done in serialization for the other non-Element classes which are allowed to be blank. * Since CreationInfo was the only non-Element class discussed for compaction, this would be the only element we allow to be referenced with an internal ID in our serialization spec. BTW - I'm completely open to making this same compaction approach available to all non-Element classes. * Even though we allow blank nodes for non-Element classes when serialized, this is not required - they can optionally be URI IDs. We may or may not need to discuss the above conclusions / assumptions - just listing them in case they become important in any of the proposed solutions. If time, I would also like to go through the backlog of other pull requests and issues: - Pull requests (2): https://github.com/spdx/spdx-3-model/pulls?q=is%3Apr+is%3Aopen+-milestone%3A 3.1+label%3Aserialization - Issues (14): https://github.com/spdx/spdx-3-model/issues?q=is%3Aissue+is%3Aopen+-mileston e%3A3.1+label%3Aserialization Gary -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5574): https://lists.spdx.org/g/Spdx-tech/message/5574 Mute This Topic: https://lists.spdx.org/mt/105053582/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
