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
