I’ll add one more question on top of this related to the namespaces.
How would we handle serialization formats that do not support namespaces (e.g. “simple JSON” or YAML)? Although we do use multiple namespaces in SPDX RDF today when referencing non-SPDX standard vocabularies, we do not have any overlaps or conflicts with the actual property or class names. If we have 2 properties with the same name (e.g. the Pressure example below), how would we represent that in a simple JSON or a YAML file? Gary From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Tuesday, April 27, 2021 11:19 AM To: Sean Barnum <[email protected]> Cc: [email protected] Subject: Re: [spdx-tech] Hoping for clarity on profile planning, model specifications, profile specifications, formal standard, etc. Really nice process diagram, Sean. I'm curious about the relationship between plans, profiles, and namespaces, illustrated with an example: To use your construction analogy, assume profiles x, y and z are Framing, Electrical, and Plumbing and all have been deconflicted by the Architecture Review Board and integrated into the model specification. Now we have an HVAC working group developing the HVAC Profile Plan. They will re-use some material from the Electrical and Plumbing profiles, because HVAC needs power and condensate drainage, but they also will create new material that doesn't yet exist. Within the model specification you show "Namespace Specifications" but no reference to X, Y and Z. I'd assume that there is an SPDX Core (a default / universal / "well-known" namespace) plus Namespace Specifications for at most X, Y and Z. Each is optional, some profiles may need nothing but the SPDX core. If that is correct, I believe it answers Gary's question about conflicting constraints. If HVAC Profile Q needs a "Pressure" attribute, and the Plumbing Profile Z defines Pressure as being 0-100 PSI, then the architecture choices are: 1) relax the constraints on Z:Pressure so that they accommodate the HVAC range of values, or 2) leave Z:Pressure as it is and define a new HVAC Q:Pressure that is 0-500 PSI. There is no conflict, because the two attributes have no relationship other than sharing the same unqualified name (and the same SI units :-). Allowing distributed development without requiring coordination is the purpose of namespaces. Yes it's nice to harmonize as much as possible to enable reuse, but when two profile working groups have fundamentally conflicting requirements, deconfliction shouldn't be a blocking issue - they can define what they need in their namespace without having to worry about conflicts with other namespaces.. So: Is it correct to say that namespaces come from profile plans, and therefore there cannot be a Q Namespace Specification unless somebody created a Q Profile Specification? If that is true, I'm not sure I see the difference between the Markdown Namespace Specification and the Profile Specification. The Formal Standard consists-of both, so the material has to exist in files somewhere. If the Profile Specification is written in Human Readable Markdown, then it *is* the Namespace Specification. Cheers, Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4049): https://lists.spdx.org/g/Spdx-tech/message/4049 Mute This Topic: https://lists.spdx.org/mt/82390442/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
