make format open/extensible by using a registry?

[dret]

it seems like there is a good set of initial values, but if that set may evolve over time to cover additional concepts. one popular model to cover this is to have a registry of values, with those defined in the original specification as the initial registry contents (https://tools.ietf.org/html/draft-wilde-registries-01). it all depends on how much this format is expected to evolve, and how easy that evolution should be. i am just pointing this out as an alternative design option for the format. i'd be more than happy to help with the specifics of establishing a registry.

[inadarei]

Erik, this makes a lot of sense. I think in the case of health checks we need to err on the side of simplicity rather than flexibility. So, as opposed to a, say, generic media type that should cover many use-cases health check media type may want to be much more restrictive for the sake of interoperability.

That said, we are already mentioning several vocabularies that have initially defined values and may need to be extended in the future.

I guess what I am saying: extensions should be limited to current shape of JSON and whatever flexibility "details" provide, no more. However, in the details we have:

1. type
2. metricName
3. merticUnit

that all could benefit from a registry for values: http://rawgit.com/inadarei/rfc-healthcheck/reusable-details/index.html

That is where I think registry would provide a lot of value here.

Do you agree?

[inadarei]

@dret do you think you can provide an example wording of how this can be featured in the healthcheck RFC?

[dret]

On 2018-01-22 00:10, Irakli Nadareishvili wrote: @dret <https://github.com/dret> do you think you can provide an example wording of how this can be featured in the healthcheck RFC?

i can do that but it would be a rather extensive re-write. so before doing that, i think it makes sense to decide if that is something that should be done. it only make sense if the set of properties is expected to grow, and if that growth should be managed through a registry. it might be interesting to look at JSON home, which has gone down this path and now is based on a registry of "resource hints", which are the properties that can be used to describe interactions with resources: https://tools.ietf.org/html/draft-nottingham-json-home-06#section-7.1

[dret]

On 2018-01-20 08:01, Irakli Nadareishvili wrote: Erik, this makes a lot of sense. I think in the case of health checks we need to err on the side of simplicity rather than flexibility. So, as opposed to a, say, generic media type that should cover many use-cases health check media type may want to be much more restrictive for the sake of interoperability.

the nice thing about a registry-based format is that in most cases, it can remain simple (only the values in the registry have to be defined and registered), while it still allows openness for others to add specific things they need. one question here is what to do about naming conflicts. i wouldn't overcomplicate things and simply use simple names and assume that unregistered ones are extension properties.

I guess what I am saying: extensions should be limited to current shape of JSON and whatever flexibility "details" provide, no more. However, in the details we have: 1. type 2. metricName 3. merticUnit that all could use from a registry for values: http://rawgit.com/inadarei/rfc-healthcheck/reusable-details/index.html

i am not so excited about these details, they seem overly detailed to me. it seems that either clients know the detail, and then they should know how to interpret it. or they don't know, and then details about metric units are of little utility. but that's something that's completely independent from the registry aspect, so i won't go into any more detail.

[dret]

i am not saying this is a great way to do it (actually, to me it is strange that they now have to keep updating the document just to add more stat details), but for reference, here is how the WebRTC statistics API handles their data model: https://www.w3.org/TR/2018/WD-webrtc-stats-20180226/

[dret]

just in case you're interested in more variations of how this could be done (all of them misguided in my mind and in need of a proper registry approach), i am maintaining a list of @w3c specs that in all likelihood should use registries, but don't: https://github.com/dret/RegMan/blob/master/W3C.md