search

netmod-wg / yang-next

Feature requests for future versions of YANG
6 stars 0 forks source link

Add support for a tuple type #77

Open rgwilton opened 5 years ago

rgwilton commented 5 years ago

Sometimes it is desirable to group multiple leaves together into the same value type that is available on a single path.

Adding native support for something like a tuple type might be an elegant way of solving this, rather than the current approach of using an adhoc string based tuple type.

Probably lots of questions of exactly what this would look like, how it would be encoded, etc. E.g. would the type parameters be named, or just numbered? How would this work with xpath/etc.

This also might be a bit of a stretch for a YANG 1.2 release, but I thought that I would gauge the interest.

abierman commented 2 months ago

This should be Must Do The XPath with current() and sibling leafs is awful and complex A tuple could make validation intent more clear to users and tools Concise syntax also CLI friendly

kwatsen commented 1 month ago

I wish Rob included an example, but I don't think it regards validation.

My first thought is, why isn't container good enough? For instance:

container rgb-color {
  leaf red {...};
  leaf green {...};
  leaf blue {...};
}
kwatsen commented 1 month ago

Rob: when having lists with multiple keys, they should be a tuple, so Xpaths can bind them together easily. Andy: hard (complexity high) Rob: other case: ip-address with prefix (not nice to have two fields encoded into one string value)

complexity high because how to do leafief

BalazsLengyel commented 1 week ago

Don't support this. Can be solved with a must statement. It increases the language complexity with not enough gain.