On 11/10/2018 17:11, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
On 11/10/2018 11:50, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
On 11/10/2018 11:21, Martin Bjorklund wrote:
Andy Bierman <a...@yumaworks.com> wrote:
On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <m...@tail-f.com>
wrote:
Andy Bierman <a...@yumaworks.com> wrote:
On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
rrah...@cisco.com>
wrote:
On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
Ladislav Lhotka <lho...@nic.cz> wrote:
> Martin Bjorklund <m...@tail-f.com> writes:
>
> > Hi,
> >
> > While reviewing restconf-notif, I saw this example:
> >
> > {
> > "ietf-subscribed-notifications:input": {
> > "stream": "NETCONF",
> > "stream-xpath-filter": "/ds:foo/",
> > "dscp": "10"
> > }
> > }
> >
> > Note the "stream-xpath-filter". It has a prefix in the XPath
string.
> > How are prefixes declared when JSON is used?
> >
> > The leaf "stream-xpath-filter" says:
> >
> > o The set of namespace declarations are those
> > in
scope on
> > the 'stream-xpath-filter' leaf element.
> >
> > (I think I provided that text...)
> >
> > This assumes that the encoding is XML, or at leas that the
encoding
> > can somehow transfer namespace declarations.
>
> It can't. There are two options:
>
> 1. have different representations of this value in XML and
> JSON,
> analogically to instance indentifiers (sec. 6.11 in RFC
> 7951).
>
> 2. use a module name rather than a prefix in XML, too.
>
> I would suggest #2.
<RR> But that means making non-backwards compatible change to the XML
representation?
Not really. It means NETMOD WG would be creating its own special
variant
of
XPath.
Not at all. What I propose is perfectly fine, legal XPath 1.0.
XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from <prefix> to <uri>,
where <prefix> is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the prefix.
It is perfectly fine to say that the prefix mapping set is this:
"ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
"ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"
and use that to evaluate the expression
/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
The XPath expression is normally parsed within an XML instance
document.
There are "xmlns" attributes present that map the prefix to a
namespace URI.
These mappings will not be present in the JSON at all.
A custom XPath implementation is required to magically identify the
prefix
as a module name and magically find the namespace URI for the module
name.
I disagree. You need an XPath implementation + custom code to set up
the environment.
This is OK, but can we just use the JSON encoding instance identifier
format exactly? I.e .RFC 7951 section 6.11.
So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
can trivially be expanded to:
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",
and then interpreted with the context:
"ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
"ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"
*this* would require a custom XPath implementation.
Why? I.e. how is this different from stating "Custom code is needed
to connect things together"?
B/c the specification of XPath allows you to (actually, *requires* you
to) construct the set of prefix strings to url mappings.
This is "custom code to connect things".
But changing the syntax means changin the specification.
Not really.
It would just mean that the filter value is not an "Xpath" expression.
It is a more a concise string that can be expanded into an Xpath expression.
and it is not obvious what the rules for the "auto-assignment" of
prefixes would be. For example:
/ietf-interfaces//ietf-ip:address[../foo]
what is the prefix for "foo"?
OK, so here the module for "../foo" would need to be specified.
Perhaps the rule that I'm looking for is the module name may be
omitted when it matches the parent node module, and can easily be
inferred. I.e. so that for any XPath string, it is possible to
trivially expand it without any additional schema context.
It just seems to be that requiring the long hand of
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled"
seems like it will get very verbose, and I wonder whether we are
introducing yet another Xpath format to YANG.
I agree that it is very verbose. But do not mix XPath expressions in
leaf values (which is what this thread is about) with
instance-identfiers.
OK, but ultimately:
- these are both leaf values.
- they both identify nodes in a YANG datastore.
- the fact that their format is somewhat subtlety different will catch
people out.
Finally, I'm trying to figure out have RFC 8040 query parameter (sect
4.8.4), which also uses XPath expressions is meant to work. That
states:
The set of namespace declarations is the set of prefix and
namespace pairs for all supported YANG modules, where the prefix
is the YANG module name and the namespace is as defined by the
"namespace" statement in the YANG module.
Perfect! It seems the authors of 8040 thought of this ;-)
OK, what you propose would at least be consistent with how the XPath is
formed in sec 8040, 4.8.4?
I can live with that. But still strongly think that WG should think of
trying to move YANG on from Xpath 1.0.
Yet the examples in section 8.3.6 don't seem to use namespace prefixes
in very many places, e.g. why is it "/example-mod:event1/name='joe'"
and not "/example-mod:event1/example-mod:name='joe'"? Is the example
wrong, or otherwise what am I missing? :-)
It seems the example is wrong!
Please can you check section 8040, 8.3.6. Are all the examples wrong?
Thanks,
Rob
/martin
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
