On Tue, Sep 30, 2014 at 11:23 PM, Randy Presuhn < [email protected]> wrote:
> Hi - > > >From: "Y. Richard Yang" <[email protected]> > >Sent: Sep 30, 2014 2:48 PM > >To: Andy Bierman <[email protected]> > >Cc: IETF ALTO <[email protected]>, [email protected] > >Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding > ... > >more general issue regarding completeness of data types in YANG: > > > >- list is an ordered array > > > >- container is a static, heterogeneous associate array > ... > > Why do you say "static"? > > It is my relative aspect, comparing list and container. The additional substatements to list (key, max-, min-elements, ordered-by, and unique) appear to me to enable more dynamic operations (the introduction of key allows insert first, last, before, after) and provide more consistency during and post dynamics (max-, min- check size, unique check duplicate, resort if ordered by). As a contrast, container is more like a (static) class definition in C++/java to provide simpler bundling. Of course, it still supports basic edit-config operations, and hence in this sense is not static at all. I am curious on if there were discussions during the design on introducing these two different types of interior nodes. In the context of key-value store example, we need the key substatement to indicate the key, and hence need to use list, but then need to implement the additional APIs such as insert first/last/before/after which have no meaning for a key value store. In other words, the key-value store appears to be a setting that may not need the helping-with-dynamic part. Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
