You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a common practice to construct namespaces using URNs to describe resources (e.g., tag or classify resources such as components, tools, and the like). It is designed to avoid collisions and also be used to construct URIs and URLs which are also common means to encode a plurality of identifiers.
Some examples lifted from linked wikipedia document include:
urn:isan:0000-0000-2CEA-0000-1-0000-0000-Y // Book ID
urn:microsoft:adfs:claimsxray // MS federated ID
urn:epc:id:gdti:0614141.12345.400 // Global Doc ID
as you can see, namespaces are constructed an urn:<org>:<domain>:<subdomain>:<...>:<value> manner; this should be allowed by syntax.
This issue requests that the syntax for CDX namespace should support URN syntax. My primary concern is that its allowed character set (pattern) would not be rejected. From current syntax, multiple ":" colon chars. are strictly disallowed.
Hoping we allow direct transfer of widely adopting URNs into properties within CDX as many companies use them in some form for federated identity and or taxonomy classification systems.
Ideally, if you indeed want simplicity, an aliasing methodology can be used (e.g., as in many schema strategies) to define a local document use of, for example:
alias: xyz:
full urn urn:http://company.xyz.com
Additionally, it should be noted that URNs are designed not to require registration as designers would construct them using unique pathing; as managing a global registration system can become untenable. Registration of values or IDs should be managed by the namespace owners.
The text was updated successfully, but these errors were encountered:
mrutkows
changed the title
Namespace syntax should support stndardized URN syntax for direct usage
Namespace syntax should support standardized URN syntax for direct usage
Apr 6, 2022
namespaces are constructed an urn:<org>:<domain>:<subdomain>:<...>:<value> manner
I would argue that the value must not be part of the property.
This means, in CycloneDX you would go - property=value-like with urn:<org>:<domain>:<subdomain>:<...>:<name>=<value>
which makes me think: why don't you just go with my-namespace:<name>=urn:<org>:<domain>:<subdomain>:<...>:<value>.
Meaning: use your URN as a value, not a property-name, and all is good.
jkowalleck
changed the title
Namespace syntax should support standardized URN syntax for direct usage
[PROPOSAL] Namespace syntax should support standardized URN syntax for direct usage
Jun 7, 2023
It is a common practice to construct namespaces using URNs to describe resources (e.g., tag or classify resources such as components, tools, and the like). It is designed to avoid collisions and also be used to construct URIs and URLs which are also common means to encode a plurality of identifiers.
See:
Some examples lifted from linked wikipedia document include:
as you can see, namespaces are constructed an
urn:<org>:<domain>:<subdomain>:<...>:<value>
manner; this should be allowed by syntax.This issue requests that the syntax for CDX namespace should support URN syntax. My primary concern is that its allowed character set (pattern) would not be rejected. From current syntax, multiple ":" colon chars. are strictly disallowed.
Hoping we allow direct transfer of widely adopting URNs into properties within CDX as many companies use them in some form for federated identity and or taxonomy classification systems.
Ideally, if you indeed want simplicity, an aliasing methodology can be used (e.g., as in many schema strategies) to define a local document use of, for example:
xyz:
urn:http://company.xyz.com
Additionally, it should be noted that URNs are designed not to require registration as designers would construct them using unique pathing; as managing a global registration system can become untenable. Registration of values or IDs should be managed by the namespace owners.
The text was updated successfully, but these errors were encountered: