On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote: > Hi Juergen, > > Is this the same as Martin's alternative B proposed previously (attached)? > Or are you suggesting a different alternative? >
Likely the same, but I admit that I do not understand Martin's comment: Con: in XML, this leaf is treated differently from other XPath expressions, such as get-config filter and nacm rules. If the context has ietf-interfaces pre-populated and you receive if:ietf-interfaces with proper XML namespace bindings, one could add the prefix if to the namespace declarations. One might even use (if the server signals that it supports prepopulated namespaces) the module name prefixed xpath expressions in say get-data. The only downside really is the verbosity but I value compatibility with xpath and no ambiguity or corner cases where things can clash higher than compactness. And a client that is capable to parse xpath and yang-library aware may do the expansion locally or if we work out the details, a server may signal its ability to do the expansion as well (not sure though that all this is effort well invested since N different ways to send around xpath expressions increases costs on all sides and is asking for interoperability problems. Hence, I rather go with longish xpath expressions for the sake of simplicity and interoperability. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod