"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
