Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps <[e-mail]>]

> On Jul 7, 2020, at 8:30 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
>> 
>> Mentioned in the earlier mail
>> 
>> instead of
>> 
>>    "decimal64"
>> 
>> use
>> 
>>    "type string { pattern '[0-9]+(\.[0-9]+)?'; }"
>> 
> 
> And then everybody implements what he/she likes? That would be a big
> step backward since every implementation will then interpret the
> numbers differently.

I dislike having to specify arbitrary limits b/c of the type. I think it would be useful to have integer and real number support that allowed for specifying "at least" precision, but not forcing the model to specify an "at most".

In generally I dislike many of the specified semantic restrictions I find in YANG models, they seem to be the most oft-cited examples of when a "backward incompatible" change might need to be made to a model.

BTW, I think decimal64 is fine for this use-case, I mainly asked on the list b/c I'm curious about the more general use-case.

Thanks,
Chris.

> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>