Re: [netmod] xpath expressions in JSON

Ladislav Lhotka <lhotka@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
> 