Ok thx. Appreciate the pointer and the ideas. Jason > -----Original Message----- > From: Martin Björklund <[email protected]> > Sent: Thursday, March 14, 2024 4:26 AM > To: Jason Sterne (Nokia) <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] structured metadata for schema nodes using YANG > extensions > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > "Jason Sterne (Nokia)" <[email protected]> wrote: > > Thanks Martin. > > > > I can see how that approach can be used to create a structure of containers > > and > leafs (where each leaf could have a type). So that's helpful for some > scenarios. > > > > I'm not sure how to deal with leaf-lists or lists though. > > > > If we wanted a leaf-list like this: > > myext:colors "red green" > > it isn't obvious to me how to extend the approaches in yang-next issue 54 to > specify it. I'm also not sure how to specify the format of the "instance > data" in the > leaf-list or if there is any sort of "right" format for that. In my example I > show > space separated names (any separator may need escape mechanisms). > > A "leaf-list" would be: > > myext:color "red"; > myext:color "green"; > > It could be specified as: > > extension color { > argument color-name { > tailf:arg-type { > type enumeration { > enum red; > enum green; > } > } > } > tailf:occurence "*"; > } > > > > > > > Similarly I'm not sure how a list could work. In theory extension > > "saturation" > could be a substatement of extension "color" and then "color" could have an > argument. That could act as a sort of list: > > Yes. > > But the approach we took was to be able to specify a grammar for > extension statements so that they could express what ordinary YANG can > do, rather than having a way to add "instance data" to a module. > > > /martin > > > > > > > extension color { > > argument "color-name"; > > } > > extension saturation { > > argument "saturation-level"; > > tailf:use-in "myext:color"; > > } > > > > Leaf foo { > > myext:color "red" { > > saturation "45"; > > } > > myext:color "blue" { > > saturation "12"; > > } > > > > Maybe another approach is to somehow allow full RFC 9195 instance data to be > the argument of an extension, and then also have some way to define the data > model of that instance data as part of the extension definition. > > > > Jason > > > > > -----Original Message----- > > > From: Martin Björklund <[email protected]> > > > Sent: Wednesday, March 13, 2024 5:08 AM > > > To: Jason Sterne (Nokia) <[email protected]> > > > Cc: [email protected] > > > Subject: Re: [netmod] structured metadata for schema nodes using YANG > > > extensions > > > > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > > links > or > > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > > > > > "Jason Sterne \(Nokia\)" <[email protected]> wrote: > > > > Hi all, > > > > > > > > I'm looking for information about doing more complex YANG extensions > > > > that the basic <name,value> type, e.g.: > > > > oc-ext:openconfig-version "2.5.0"; > > > > > > See https://github.com/netmod-wg/yang-next/issues/54 for a discussion > > > about one approach. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > The node-tags approach doesn't fit what I'm trying to do (tags can't > > > > have values). > > > > > > > > RFC7950 says the following: > > > > The substatements of an > > > > extension are defined by the "extension" statement, using some > > > > mechanism outside the scope of this specification. Syntactically, > > > > the substatements MUST be YANG statements, including extensions > > > > defined using "extension" statements. > > > > > > > > Let me start with a simple example and build on it. Say I want to > > > > associate a color with any schema node. That's easy: > > > > > > > > extension color { > > > > argument "color"; > > > > description "Takes a value of red, green or blue"; > > > > } > > > > > > > > leaf foo { > > > > myext:color "red"; > > > > } > > > > > > > > But what if I want a more complex structure for my color metadata like > > > > this? (a leaf-list and leaf inside a container) > > > > > > > > leaf foo { > > > > myext:chroma-metadata { > > > > myext:colors "red green"; > > > > myext:saturation "45"; > > > > } > > > > > > > > >From what I can tell, I'd have to define it like this: > > > > > > > > extension chroma-metadata { > > > > } > > > > extension colors { > > > > argument "color-list"; > > > > description "sub-statement of chroma-metadata. Space separated > > > > list > of > > > > colors red, green and blue."; > > > > } > > > > extension saturation { > > > > argument "saturation-level"; > > > > description "sub-statement of chroma-metadata"; > > > > } > > > > > > > > Or if I wanted a list like this? > > > > > > > > myext:chroma-metadata { > > > > myext:color "red" { > > > > myext:saturation "45"; > > > > } > > > > myext:color "green" { > > > > myext:saturation "23"; > > > > } > > > > } > > > > > > > > I don't think there is any formal way to do it, but could I say that > > > > the structure of the chroma-metadata follows a grouping I define? > > > > > > > > grouping cm-struct { > > > > list color { > > > > leaf saturation { ... } > > > > } > > > > } > > > > > > > > Could another option be to just define the top level extension > > > > chroma-metadata with a single argument, and then describe that the > > > > argument itself is a json-ietf blob of instance data that conforms to > > > > YANG grouping xyz? > > > > > > > > Jason (he/him) > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
