> On 16 Dec 2015, at 18:04, Christian Hopps <[email protected]> wrote: > > > Andy Bierman <[email protected]> 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 possibility of (leaf-)list entries being interleaved with other sibling XML elements is explicitly mentioned in RFC 6020 (sec. 7.7.6 and 7.8.5). This shouldn't come as a surprise because XML has no notion of lists. > 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. :) >> - 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? Absolutely. Lada > > Thanks, Chris. > >> Andy >> >> >> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps <[email protected]> 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 >>> [email protected] https://www.ietf.org/mailman/listinfo/netmod >>> >>> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
