On 29 Oct 2019, at 10:23, Carsten Bormann wrote:
On Oct 29, 2019, at 15:16, Pete Resnick <resnick@xxxxxxxxxxxx> wrote:
Add the scale column to the main registry and use one registry.
The two registries have different policies (not in RFC 8228
nomenclature but in DE practice).
But you haven't justified not simply changing the policy for the primary
registry. Make the DE practice, "Add it to the registry if it's a base
unit or if it's in common use in another SDO."
If we treat entries with scale different from entries without scale,
this is exactly equivalent to having two registries.
But that has not been the recommendation.
Except that it is trivial to write a program to curl the second
registry and convert a random SenML file to a clean main-registry-only
file. If these are muddled, you of course can write a slightly longer
program.
I don't understand that statement.
The main difference remains one of signaling. How the signals
emanating from a standards document actually influence the world is
usually
not very well understood, so I can see why different people would have
different opinions here.
There's signaling to implementers ("You have to deal with all of these
entries") and then there's signaling to the outside world. We certainly
want to get the former right, and there should be little difference of
opinion there. On the latter, I actually think we agree:
I’d still prefer to signal that there is a clear difference between
using SI base units and furlongs per fortnight, and decent SenML
processors, given a choice, should do the former.
That's a job for the DE, and can be expressed in the instructions to the
DE.
(And I definitely want to signal that SenML is open for business, but
I think we are discussing alternatives that are roughly equivalent in
that respect, not sending away those other SDOs at the door.)
Which is exactly why you should keep these in one registry: SDOs don't
have to have second class citizenship in the registry.
There's no upside to keeping two, as far as I can tell, and there's
definitely the potential for interoperability problems.
I think Ari’s point stands.
I'm not sure which one.
What we could do is make it more explicit that a SenML implementation
now has to heed both registries. But there never was a MUST on
actually being able to process all registry 1 entries anyway, so I
don’t quite know what that would mean for registry 2.
If the two registries have equivalent rules of use, that further
justifies one registry to make sure they don't get treated differently.
We did everything that is needed to make it *easy* to implement
registry 2, apart maybe from asking IANA to provide a JSON file with
the registrations.
It seems that ease of use is increased with one registry instead of two.
Your justifications for the second registry really make no sense to me;
it seems to me that all of them lead you to the conclusion that there
should be one registry.
Singapore is 3 weeks away. Perhaps you'd like to have 5-10 minutes on
the agenda?
pr
--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best
