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.

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 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:
Created 6 years ago
Comments:7 (6 by maintainers)

Top GitHub Comments

1reaction

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:

0reactions

rufuspollockcommented, Jun 15, 2020

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

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

How to add namespace to Attribute for XML profile request.

I want to format as xsi:type and parameters as another element inside authentication.

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

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

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