yang canonical integer format

[schoenw]

The canonical format for integer types is the decimal representation. We do not seem to have a mechanism (other than a description statement) to declare that the canonical representation is lets say hexadecimal. For example, EtherType values are usually written in hexadecimal notation. If I use a plain uint16 to represent an EtherType, it comes out of a datastore rendered as a decimal number - and all I have is a description statement... Would be nice to say something like

  typedef ether-type {
    type uint16 { format "%x"; }
  }

[schoenw]

Nice to have, not crucial.

[kwatsen]

This would help the CBOR WG

[kwatsen]

maybe an encoding hint would be more backwards-compatible, in an "updating inet-types.yang" perspective:

typedef ether-type { type string { encoding "unit16"; } }

[schoenw]

Why does this help CBOR? This is about the representation of number, not about encoding the number. CBOR would encode an integer as major type 1 or 2 regardless of the formatting hint. I do not understand the example either. This is about having %x and friends in addition to %d hardwired for numbers.

Perhaps this is actually a bad proposal since what we are likely talking about here is a rendering for the presentation to the user, not for encoding purposes; having a single representation in the (XML) encoding for numbers is like a feature and not a bug. Introducing a "%x" format hint would really be a 'display hint' (sorry for using an old term) for user facing software and it should not be confused with an 'encoding hint'. Note that the difference matters, lets take JSON, which distinguishes between numbers and strings and as far as I can tell can't deal with numbers that are not rendered as something that matches 'number = [ minus ] int [ frac ] [ exp ]'.

It this is really a presentation issue, then this can all be done with extensions I think (since it does not affect any encodings).

[mbj4668]

I think that it is a bit odd that we allow default values for an integer to be in hexadecimal or octal form, but this notation is not allowed in the XML. So maybe we should do two things: allow hex/octal in XML, and add a display-hint that can be used for user facing software. JSON would still encode as decimal numbers, and CBOR in binary form.

[schoenw]

Its a feature and not a bug that we use a single canonical representation on the wire. The default value is read by a YANG parser, not by a parser reading on the wire data. What the format statement would do is giving a presentation hint, no more no less. The differences between these things should be clear when you look at CBOR encoding.

[rgwilton]

This issue seems loosely related to #46, in that some numerical values (e.g. IP address, MAC address, ethertype) are modeled as strings to give them a more human readable representation.

[kwatsen]

No longer relevant.