Re: [T2TRG] [Asdf] [One Data Model Group] Representation issues and protocol bindings

[Alexander Pelov <[e-mail]>]

Hi Carsten, all,

These are indeed some interesting questions, and I am not sure to
what extent they can be solved in a generic way.

In our work on adding parsing capabilities to YANG files (see
https://tools.ietf.org/html/draft-petrov-t2trg-youpi-01 ) we've done some
of the things you mentioned. For example, in YANG you have the built-in
capability to describe the range of a value, e.g. if it goes from 0-100, or
from 1-255. That of course would solve the first part of your question.

I think that solving the full problem may be a little bit more delicate.
For example, someone just might choose 0-1000, where 0 is max brightness,
which then goes to min brightness at around 950 and then again to maximum
brightness at 1000. Why would anyone do something like this? I think the
question would be mostly - if someone does it, how to handle it graciously.
There may be something like a mapping, two-way function, that first
transforms the crazy thing into a linear graduation, which can then be
handled in a more "understandable" way.

So probably, a combination of the two:
1) having the hypothesis that a variable is "linear", with known MIN/MAX
2) annotating the MIN/MAX values (e.g. 0=off, 255=bright)
2.1) optionally annotation intermediate values (e.g. 10=very dim)
3) having an (optional) transformation function to/from the linear function
used by ASDF (in case the variable is not linear)

Cheers,
Alexander


On Mon, Aug 31, 2020 at 5:22 PM Milan Milenkovic <[e-mail]> wrote:

> Hi Karsten, Wouter et al.
>
> For your example, I was going to suggest the range fraction or % solution
> but Wouter beat me to it.
>
> More importantly, I think we should be pragmatic and aim for the 80%
> solution (which, according to the Pareto principle, may require definition
> of only 20% of use cases ;-).  IMO, luminosity ad brightness are examples
> of a relatively skewed minor use case in a specific domain that is
> consuming disproportionate amounts of time and effort to address and that
> complicates many a solution for what is at best a small benefit.  Such
> things can be tabled, and possibly revisited later, to allow progress on
> solutions for the most common use cases.
>
> Regards,
> Milan Milenkovic, Principal
> IoTsense LLC, www.iotsense.com, [phone]
>
> -----Original Message-----
> From: One Data Model Group <[e-mail]> On Behalf Of Wouter van
> der Beek (wovander)
> Sent: Monday, August 31, 2020 7:51 AM
> To: Carsten Bormann <[e-mail]>; [e-mail]
> Cc: One Data Model Group <[e-mail]>; [e-mail]
> Subject: RE: [One Data Model Group] [Asdf] Representation issues and
> protocol bindings
>
> Hi Carsten,
>
> I think using JSON as a notation actually helps, It avoids using the more
> precise thus more prescriptive  int32/64/... data types.
> e.g. just Boolean, number and integer as base.
>
> Enum values I hope everyone will start using string value as enum value,
> where the string can have an actual meaning, e.g.
> State = ["stopped, "running", "broken"] instead of [1,2,3] ...
>
> As example I think brightness should be expressed as % in number so that
> one can choose its precision on the wire.
> All examples of 0-254, 0-100, 0..65535 Are ok with me with a specific
> mapping.
> So if one encounters the brightness on system A one should know the actual
> data on the wire so that one can map it to the oneDM model in SDF. If one
> needs to use it on system B, one needs to know how to write the data on the
> wire for System B.
> (note that this only works when everything can be mapped linear, so even
> this simple example is not that simple).
>
> And if there is a need (e.g. origin from an contributing org) we can add
> the more precise int32 as sub type.
> But I think we all experienced that over time resolutions go up, good
> example of this is RGB,  0-255- 8 bits, then 16 bits, 24 bits ...
>
> So I rather would go for the 80% solution, which is already 80% more than
> what is there today.
>
> Kind Regards,
> Wouter
>
> -----Original Message-----
> From: ASDF <[e-mail]> On Behalf Of Carsten Bormann
> Sent: Monday, August 31, 2020 3:26 PM
> To: [e-mail]
> Cc: One Data Model Group <[e-mail]>; [e-mail]
> Subject: [Asdf] Representation issues and protocol bindings
>
> In today’s OneDM call, Bruce Nordman brought up the issue that, in the
> end, we’ll need concrete representations to talk to devices and use their
> data.
>
> So if we have one ecosystem that uses 0..100 for describing the brightness
> setting for a lamp, another one that uses 0..254 (where 255 means something
> complete different), and a third with 0..65535, what do we do?  (And these
> might also differ whether they describe a emitted light power level or a
> perceptive luminous flux level.)
>
> The underlying problem is that we are abusing data model level description
> techniques (in part borrowed from json-schema.org) to describe
> information models.
> That works reasonably well until we start taking these data model level
> descriptions at face value.  The fact that some converged model uses a
> scale based on the L component of Lu’v’ does not mean that everybody has to
> represent their ecosystem model the same way.
>
> The obvious second problem is that we haven’t tackled a framework for
> describing protocol bindings (which, initially, will mostly be ecosystem
> bindings).  That would be the place where we say how the L component needs
> to mapped to the ecosystem specific concrete representation.  Since that
> mapping, in principle, can have arbitrary complexity, completely covering
> all cases requires Turing-equivalent functionality in a description
> language.  Or we could go for an 80 % solution and then, for the 20 %,
> register mapping components that are more complex in an IANA registry.
>
> Let’s discuss this based on some real-world examples — it is easy to
> construct artificial ones that have more complexity than we actually need.
>
> CCing T2TRG as well because quite a few people there are familiar with the
> problem; maybe we want to have the bulk of the discussion on [e-mail]
> though.
>
> Grüße, Carsten
>
> --
> ASDF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/asdf
> --
> ASDF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/asdf
>