Hi Reshad,
Please see RW: inline.
On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
Hi Rob,
*From: *netmod <netmod-boun...@ietf.org> on behalf of "Robert Wilton
-X (rwilton - ENSOFT LIMITED at Cisco)" <rwil...@cisco.com>
*Date: *Thursday, October 11, 2018 at 7:17 AM
*To: *Martin Bjorklund <m...@tail-f.com>
*Cc: *"netmod@ietf.org" <netmod@ietf.org>
*Subject: *Re: [netmod] xpath expressions in JSON
On 11/10/2018 11:50, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com><mailto:rwil...@cisco.com>wrote:
On 11/10/2018 11:21, Martin Bjorklund wrote:
Andy Bierman
<a...@yumaworks.com><mailto:a...@yumaworks.com>wrote:
On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
<m...@tail-f.com><mailto:m...@tail-f.com>
wrote:
Andy Bierman
<a...@yumaworks.com><mailto:a...@yumaworks.com>wrote:
On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman
(rrahman) <
rrah...@cisco.com<mailto:rrah...@cisco.com>>
wrote:
On 2018-10-10, 9:59 AM, "netmod on behalf
of Martin Bjorklund" <
netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>on
behalf of
m...@tail-f.com<mailto:m...@tail-f.com>> wrote:
Ladislav Lhotka
<lho...@nic.cz><mailto:lho...@nic.cz>wrote:
> Martin Bjorklund
<m...@tail-f.com><mailto: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"?
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.
<RR> I’m willing to live with verbosity if it avoids the need of
another format.
RW:
This is already looks like another format:
Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241 sec
8.9.5.1
<filter xmlns:t="http://example.com/schema/1.2/config";
type="xpath"
select="/t:top/t:users/t:user[t:name='fred']"/>
</get-config>
The standard JSON encoding for instance-data (IIRC, the same scheme is
used for CBOR) uses the module-name but omits it where it matches the
parent (e.g.
"/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled")
RFC 8040 query parameter is as described below, but having looked at the
examples I'm not really sure how that is meant to work :-)
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.
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? :-)
<RR> Section 8.3.6 of which document?
RFC 8040.
Thanks,
Rob
Regards,
Reshad.
Thanks,
Rob
/martin
Thanks,
Rob
There is no standard XPath implementation that can just
take an XML
instance document + YANG module and figure out what to
do. Custom
code is needed to connect things together. This proposal
doesn't
change this.
/martin
A normal XPath implementation will not find any
namespace mapping for
the
prefixes.
An XPath expression has no concept of the "current
module" inherited
from
the parent
like the JSON encoding. This is problematic for predicates
/ietf-interfaces:interfaces/interface[name='eth0']
XPath says the missing prefixes for 'interface' and
'name' are simply
missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for
'interfaces'. and
'interface'.
There is no specification for the 'name' node inside a
predicate.
So you must mean the full module name will be used at
every node:
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']
/martin
Andy
Hmm, so you mean change the leaf
"stream-xpath-filter" to say:
o The set of namespace
declarations has one member for
each
YANG module supported by
the server. This member maps
from the YANG module name
to the YANG module namespace.
This means that in the
XPath expression, the module
name
serves as the prefix.
.... and then also give an example of
this.
This is probably what we need to do
in all places where
yang:xpath1.0
is used, going forward. Maybe even
define a new type
yang:xpath1.0-2 (name?) with the set
of namespace declarations
built-in.
We should avoid making off-the-shelf
implementations of standards like
XPath unusable.
At the very least this should be only
available if the server supports
it
(with a capability URI)
<RR> So we need an update to RFC7951?
Regards,
Reshad.
Andy
/martin
>
> Lada
>
> >
> > How is this supposed to work with
JSON?
> >
> >
> > /martin
> >
> >
_______________________________________________
> > netmod mailing list
> >
netmod@ietf.org<mailto:netmod@ietf.org>
> >
https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
..
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
