Gary,
OpenC2 does that by assigning a property name to each namespace, then
including types from that namespace below the property.
Type names, which can be namespaced, never appear in JSON data. Namespace
property names MAY be the same string as XML prefixes, but there's no
technical requirement for them to be. A schema that defines:
namespaces = '{"pb": "http://example.com/plumbing/v1.2";, "hv": "
http://example.com/hvac/v1.0"}
SensorReading = Record
1 sensorSwid SpdxRef
2 water_pressure pb:Pressure optional
3 outdoorHiPressure hv:Pressure optional
4 outdoorAirTemp hv:DegreesCelsius optional
could have a JSON value of:
{
"sensorSwId": "SPDXRef-34",
"waterPressure": 62,
"outdoorHiPressure": 231
}
More scalably, the schema would define namespace mountpoints and the
namespaced schema would have a top-level object
listing its attributes:
SensorReading = Record
1 sensorSwid SpdxRef
2 plumbing/ pb:Pressure optional
3 hvac/ hv:Pressure optional
which would be serialized as:
{
"sensorSwId": "SPDXRef-34",
"plumbing": {
"pressure": 62,
},
"hvac": {
"temp": 72,
"pressure": 231
}
}
Attribute references use RFC 6901; the attribute pathnames for
SensorReading would be:
"sensorSwId"
"plumbing/pressure"
"hvac/temp"
"hvac/pressure"
Dave
On Tue, Apr 27, 2021 at 6:22 PM Gary O'Neall <[email protected]> wrote:
> 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 (#4050): https://lists.spdx.org/g/Spdx-tech/message/4050
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]]
-=-=-=-=-=-=-=-=-=-=-=-
