On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote: > 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.
This may be the best option: the "verbose" prefix/namespace bindings will be available in all encodings, which doesn't prevent users of the XML encoding to define additional ones. I would suggest to extend the definition of the "xpath1.0" type with the corresponding specification of the default XPath context. Lada > > 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 > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
