Ladislav Lhotka <lho...@nic.cz> wrote: > 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.
Yes, and we can define a canonical format (with module names), and it is backwards compatible. The only problem is verbosity, but I think that is unavoidable. > I would suggest to extend the definition of the "xpath1.0" type with the > corresponding specification of the default XPath context. Yes, something for 6991bis. Meanwhile, for SN, we can add this already there for stream-xpath-filter. /martin > > 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
