Adding a version to profile attribute (or doing this via a "spec" namespace)
See original GitHub issuev1 is here! Going forward, we will have to have ways to handling different spec versions, and specifically, implementors will need to be able to rely on some metadata for this.
Status
- 👍 on supporting recording of version
- RECOMMENDED: Use urls for profiles and do versioning in url - see #689
- If we didn’t go for that, keep
profile
single value and use@
eg.profile: "data-package@1.0"
Original Proposal
Towards this end, I propose adding a spec
property, which is a namespace for this purpose. One can think of this namespace as being metadata for the descriptor itself, rather than metadata for the data.
At this stage, there are two properties that would live in the spec namespace:
profile
: This property has landed in v1version
: This property has not yet been added to the specifications, but the need has been established and it will be vital for implementors going forward
"spec": {
"profile": "tabular-data-package",
"version": "1.0.0"
}
In the absence of the spec
property, defaults are to be assumed:
spec.profile
- the same as the currentprofile
definitionspec.version
- the current specification version
This property should apply to all specifications.
For related discussions, see #403 (use namespaces in DP - WONTFIX), #399 (introduce version - WONTFIX at time and reference to this issue for future changes) and #103
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Specifying Namespaces for Elements and Attributes
You can make a property into a global element and assign it to a namespace. To do so, you set the XMLREF property...
Read more >How to add namespace to Attribute for XML profile request.
I want to format as xsi:type and parameters as another element inside authentication.
Read more >Using profiles with Compose - Docker Documentation
Services are associated with profiles through the profiles attribute which takes an array of profile names: version: "3.9" services: frontend: image: ...
Read more >Namespaces in XML 1.0 (Third Edition) - W3C
XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by ...
Read more >Create and Configure a vSphere Namespace - VMware Docs
Namespaces that you create on a Supervisor Cluster configured with the vSphere networking stack only support Tanzu Kubernetes clusters and VMs, ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I generally like the idea of reducing “magic” for the profile field and using raw URLs. Is there is a plan to drop Data Package Identifier spec also (not implemented anywhere)? It’s another “magic” or one-point-of-failure area making general specifications to be vendor-locked.
I think we can have endpoints on the specs site to publish profiles:
@roll glad you like this approach and agree on deprecating
data-package-identifier
spec. Also agree on endpoint style.