Re: [netmod] xpath expressions in JSON

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> 
> 
> On 11/10/2018 11:50, Martin Bjorklund wrote:
> > Robert Wilton <[e-mail]> wrote:
> >>
> >> On 11/10/2018 11:21, Martin Bjorklund wrote:
> >>> Andy Bierman <[e-mail]> wrote:
> >>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <[e-mail]>
> >>>> wrote:
> >>>>
> >>>>> Andy Bierman <[e-mail]> wrote:
> >>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>>>> [e-mail]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> >>>>>>> [e-mail] on behalf of [e-mail]> wrote:
> >>>>>>>
> >>>>>>>       Ladislav Lhotka <[e-mail]> wrote:
> >>>>>>>       > Martin Bjorklund <[e-mail]> 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.

> > 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.

> 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 ;-)

> 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!


/martin