Re: [YANG] deep keys and unique statements

Martin Bjorklund píše v Po 21. 01. 2008 v 10:17 +0100:
> Ladislav Lhotka <lhotka@cesnet.cz> wrote:
> > Andy Bierman píše v Pá 18. 01. 2008 v 08:23 -0800:
> > > On the other hand, the unique-stmt allows arbitrary combinations
> > > of leaf instances anywhere within the list.  The complexity
> > > built into the unique-stmt is extensive, as even a 2-d table shows:
> > 
> > I am thinking about an alternative "upside-down" implementation of both
> > key and unique properties, namely to declare these properties with the
> > leaf. The semantics would be that these properties always pertain to the
> > nearest ancestor list (if any, otherwise it is noop). Example:
> > 
> > list aaa {
> >   container bbb {
> >     leaf c {
> >       type c-type;
> >       unique;
> >     }
> >   }
> > }
> 
> This doesn't work if it is the combination of two leafs that is
> unique.  In this example, the name has to be unique, and also the
> ip/port combination:

In RELAX NG we enclose the two elements in a group pattern and attach
the property to that group. Perhaps grouping statement could be used for
this purpose in YANG?

> 
>   list server {
>     key "idx";
>     unique "ip port";
>     unique "name";
> 
>     leaf idx { ... }
>     leaf ip { ... }
>     leaf port { ... }
>     leaf name { ... }
>   }
> 
> [Side note: In our current DML we took the approach you describe, but
> in order to handle the combinations, the unique statement took an
> argument which was a tag.  All leafs with the same tag would be
> checked in combination.  I think the YANG statement is more clear.]
> 
> > There are two advantages:
> > 1. The scope of the property - nearest ancestor list - is always unique,
> > so no XPath expressions are needed here.
> > 2. At the time when the declaration is read the entire ancestor chain is
> > known, i.e., no buffering is needed.
> 
> I don't understand these advantages.  Are you talking about buffering
> in the compiler?

I mean this: If the validator is checking a configuration value and
finds in the schema that it is declared as unique, it can immediately
tell whether the value is unique within the configuration read so far.
In a YANG-like implementation with deep keys, it would have to buffer
all unique declarations as long as it is inside the list and determine
first for each leaf instance in the configuration whether it was
previously declared as unique. I assume the validator walks down the
hierarchies of configuration data and the schema in parallel, it may not
be an issue if you compile the schema into another representation.

> 
> 
> > 
> > If I remember correctly, the main objection against this implementation
> > is that it would be difficult to declare keys a posteriori for standard
> > groupings, but I think it could be handled by extending the augment
> > statement, e.g, like this:
> >
> > module inet-extra {
> >   ...
> >   grouping endpoint {
> >     leaf address {
> >       type inet:address;
> >     }
> >     leaf port {
> >       type uint16;
> >     }
> >   }
> >   ...
> 
> I think it would be the uses refinement that would be used (not augment):
> 
>   list foo {
>     uses iex:endpoint {
>       leaf address {
>         key true;
>       }
>     }
>   }
> 
Yes, this looks nice.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang