-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
[PROPOSAL] Namespace syntax should support standardized URN syntax for direct usage #9
Comments
This is a great idea IMO |
The full set of URN does not actually make sense here, right? As the property describes a "kind", not a dedicated value, right? As you wrote, @mrutkows
I would argue that the This means, in CycloneDX you would go - which makes me think: why don't you just go with What do you think, @mrutkows , @coderpatros ? |
can we close this, @mrutkows? |
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: