On 11/10/2018 10:21, Andy Bierman 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.
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']
Hum, that is going to make these expressions very long, and not
particularly human readable.
The XPath 1.0 spec that YANG using is effectively obsoleted by newer
(much more complex) versions. I doubt that this will be liked, but my
view is that the longer term solution here is for a bespoke "YANG Path"
language to be specified, closely based on XPath 1.0, but fixing some of
the issues that we have using XPath for YANG constraints (e.g. it is
easy to get them wrong), and removing some of stuff that isn't helpful
(e.g. node tests, processing instructions, etc).
Thanks,
Rob
/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
<https://www.ietf.org/mailman/listinfo/netmod>
> > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> >
> > _______________________________________________
> > netmod mailing list
> > net...@ietf..org <mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org <mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
