On Wed, Dec 16, 2015 at 9:04 AM, Christian Hopps <cho...@chopps.org> wrote:
> > Andy Bierman <a...@yumaworks.com> writes: > > Hi, >> >> Use of NP-containers are subjective, based on how you want to organize >> your data. The extra layer of containment may be a waste, but it sometimes >> has a purpose >> >> - 2 or more sibling lists with lots of entries can be mixed in JSON, >> so putting each list in its container prevents that. >> > > Did you mean XML here (Lada indicated it's not the case with JSON)? I was > curious if mixing like this was allowed in XML case (whether items from 2 > different lists or even sibling leafs). I was hoping that once a list > started in the XML all items in the list would be present before other > items outside the list. If what your saying applies to XML then one would > have to iterate all sibling nodes in the containing node to collect the > list. This would seem to be the case even with sibling leafs in the model. > I find this a bit surprising, and would expect bugs in implementation if > so. :) > Lada is correct so ignore this use-case > - container servers as a conceptual 'root' for external augments >> > > This might be useful in some cases, probably not a reason to always > include a container wrapper though. > >> - There is no standard way to 'delete-all' in NETCONF or RESTCONF >> but a 'replace' on the parent container can be used for this purpose. >> (container of list or leaf-list) >> > > This is an interesting use -- using a modeling technique to to get around > missing functionality in the protocol (hello opstate! :) > Seriously though, should we consider adding delete-all functionality then? > Maybe in the future if NETCONF gets updated > Thanks, Chris. > Andy > > Andy >> >> >> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps <cho...@chopps.org> >> wrote: >> >> >>> Some models seem to place a single list of things inside a container >>> also named after the items in the list, e.g., >>> >>> +--ro modulename +--rw ribs +--rw rib* [name] +--rw name >>> I don't see the purpose of these containers. It seems to me that one can >>> model and query the exact same data without the outer container. That is, >>> >>> +--ro modulename +--rw rib* [name] +--rw name Is there something >>> useful about these containers that I've missed, as it's a fairly common >>> pattern in the models I've been looking at. Example comparisons below.. >>> Thanks, Chris. >>> >>> >>> w/ container: <modulename> <ribs> <rib> >>> <name>foo</name> </rib> <rib> <name>bar</name> </rib> ... >>> </ribs> </modulename> w/o container: <modulename> <rib> >>> <name>foo</name> </rib> <rib> <name>bar</name> </rib> ... >>> </modulename> Likewise if you want to fetch all ribs you can either way: >>> >>> <filter> <modulename> <ribs/> </modulename> >>> </filter> or >>> >>> <filter> <modulename> <rib/> </modulename> >>> </filter> Or a particular rib >>> >>> <filter> <modulename> <ribs> <rib> >>> <name>foo</name> </rib> </ribs> </modulename> >>> </filter> or >>> >>> <filter> <modulename> <rib> <name>foo</name> >>> </rib> </modulename> </filter> Using xpath: >>> >>> /modulename/ribs/rib[name='foo'] or >>> >>> /modulename/rib[name='foo'] >>> >>> _______________________________________________ netmod mailing list >>> netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
