Introduce an annotation that resolves the union member

[llhotka]

Determining the union member to be used for a given instance is a fragile and potentially demanding process that may also depend on the instance representation.

The (optional) annotation would pinpoint the member type so that no guesswork is needed. If it is not used, the existing algorithm applies.

The annotation has to be able to deal with unions inside unions (any number of levels).

[immibis]

Is the union member actually a valid concept in YANG?

Obviously something like this is useful for programming language mappings.

[abierman]

agree this is Must Do YANG union should be consistent across encodings.

not easy to specify current algorithm is to go through the member types in order and first match wins.

may not be BC change in YANG parsing

definitely requires new encoding rules and new protocol versions

[abierman]

solution to this issue is needed by #133

• cannot use type name since not all types are named. inline types are common.
• It may be too complex to serialize all nested union types into 1 number.

Possible solution

Prepare types (conceptual)

• replace all leafrefs with their final referenced type
• replace all named types with their equivalent simple types

Procedure:

• Record the member type position of the matched type in an array.
• member types are numbered from 1 .. N
• value 0 reserved for 'not set'
• Start a new array level if union within a union

Example: a boolean would be tagged as 3.1

leaf test {
   type union {     // top-level union not not seed a number
      type int8;   // type 1
      type int16;  // type 2
      type union {   // type 3
          type boolean;  // type 3.1
          type enumeration { enum ... } // type 3.2
      }
      type string;   // type 4
    }
}

[cabo]

IIRC, it is a backwards compatible change to add types to the union. Maybe even to shuffle them around.

But anyway, we have tags for identifying "alternatives" in CBOR, please see

https://www.ietf.org/archive/id/draft-bormann-cbor-notable-tags-11.html#name-enumerated-alternative-data

So if we find a way to attach numbers that stick, we can use those right away.

[abierman]

Numbers that stick have proven to be incompatible with actual vendor deployment. The NBC Change is a Big Deal in NETMOD WG. Vendors do not follow the rules 100% Vendors use deviations that change the base type (sigh). YANG in the wild depends on the client having the YANG library and YANG modules from the actual server.

IMO the position of the implemented type and a base-type-code are needed.

typedef foo {
    type union {
       type enumeration { A B C }
       type enumeration { D E F }
       type identityref { base foo; }
       type identityref { base bar; }
       type string { pattern X; }
       type string { pattern Y; }
    }
}

What if the first number in the array is a 1 byte code for YANG base type, as a sanity check for the decoder? Numbers 2 - N represent the member type that matched. E.g if boolean is type 6, then the boolean in my example is '6.3.1' For types like enumeration, bits, identityref, string, decimal64, knowing the base type is not enough.

Remembering old ordering is difficult and not done now. The YANG library details are supposed to change if a module is changed at all.

YANG Push usage and CoAP usage have different requirements.

[abierman]

YANG 2.0 must consider XML, JSON, and CBOR encoding requirements. YANG 1.1 assumes XML.

[cabo]

On 31. Aug 2024, at 19:52, Andy Bierman @.***> wrote:

YANG 2.0 must consider XML, JSON, and CBOR encoding requirements. YANG 1.1 assumes XML.

Actually, the fun part is that RFC 7951 has different rules for selecting union branches from RFC 7950. (JSON has more type information than XML, and RFC 7951 says that this information must be used.)

Grüße, Carsten

[janlindblad]

I agree so far as the wire encoding needs to be clear, but maybe that is for each protocol (NC/XML, RC/JSON, CBOR etc) to describe, rather than YANG 2.0? When it comes to the programming language mapping, I don't think that should be part of YANG 2.0. I'm definitely against that a client should be required to annotate the values it sets with some sort of type information à la "6.3.1".

[kwatsen]

Juergen: a lot of unions out there. need to add a new discriminated union identifier. if solution done right, backwards-compatibility is high.