Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Adding a version to profile attribute (or doing this via a "spec" namespace)

See original GitHub issue

v1 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.


  • 👍 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 v1
  • version: 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 current profile definition
  • spec.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:open
  • Created 6 years ago
  • Comments:7 (6 by maintainers)

github_iconTop GitHub Comments

rollcommented, Jun 15, 2020

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:

rufuspollockcommented, Jun 15, 2020

@roll glad you like this approach and agree on deprecating data-package-identifier spec. Also agree on endpoint style.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found