Re: [YANG] deep keys and unique statements

[Ladislav Lhotka <[e-mail]>]

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;
    }
  }
}

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.

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;
    }
  }
  ...

import inet-extra {
  prefix iex;
}

augment "/iex:endpoint/iex:address" {
  key;
}

Lada

  
> 
> 
>    list foo {
>      // all nodes except the key leafs (x, c, d) are optional
>      config true;
>      key x;
>      unique "y bar/a baz/e baz/c";
> 
>      list bar {
>        config false;
>        leaf a { type int32; }
>        leaf b { type string; }
>      }
> 
>      list baz {
>        key "d c";
>        leaf c { type float32; }
>        leaf d { type float64; }
>        leaf e { type binary; }
>      }
> 
>      leaf x { type instance-identifier; }
>      leaf y { type keyref { path "baz/c"; } }
> 
>    }
> 
> 
> The agent has to check all the instances of all the leafs and only
> enforce uniqueness in the entries that are complete.  One missing
> optional leaf, and the entire unique-stmt is ignored instead (for that
> entry).
> 
> Besides this unbounded complexity, it seems very odd for
> the leafs within the nested lists (bar and baz) to have
> uniqueness constraints placed 'from above', since they are
> not required to be unique within the list that defines the leafs.
> 
> It also seems broken that config and non-config leafs can be
> combined in the uniqueness test.  The 'config' and 'unique'
> statements are not relevant in notification data, so is it
> an error or just no-op if they are entered for notification
> data-def-stmts?  (Could be from uses expansion as well.)
> (Note that keyref adds an indirection twist to the complexity.)
> 
> Andy
> 
> 
> 
> 
> _______________________________________________
> YANG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/yang
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C



_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang