Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka <[e-mail]>]

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