Re: [netmod] xpath expressions in JSON

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> Hi Reshad,
> 
> Please see RW: inline.
> 
> 
> On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> >
> > Hi Rob,
> >
> > *From: *netmod <[e-mail]> on behalf of "Robert Wilton -X
> > *(rwilton - ENSOFT LIMITED at Cisco)" <[e-mail]>
> > *Date: *Thursday, October 11, 2018 at 7:17 AM
> > *To: *Martin Bjorklund <[e-mail]>
> > *Cc: *"[e-mail]" <[e-mail]>
> > *Subject: *Re: [netmod] xpath expressions in JSON
> >
> > On 11/10/2018 11:50, Martin Bjorklund wrote:
> >
> >     Robert Wilton <[e-mail]><mailto:[e-mail]>wrote:
> >
> >         On 11/10/2018 11:21, Martin Bjorklund wrote:
> >
> >             Andy Bierman
> >             <[e-mail]><mailto:[e-mail]>wrote:
> >
> >                 On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
> >                 <[e-mail]><mailto:[e-mail]>
> >
> >                 wrote:
> >
> >                     Andy Bierman
> >                     <[e-mail]><mailto:[e-mail]>wrote:
> >
> >                         On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman
> >                         (rrahman) <
> >
> >                     [e-mail]<mailto:[e-mail]>>
> >
> >                         wrote:
> >
> >                             On 2018-10-10, 9:59 AM, "netmod on behalf
> >                             of Martin Bjorklund" <
> >
> >                             [e-mail]<mailto:[e-mail]>on
> >                             behalf of
> >                             [e-mail]<mailto:[e-mail]>> wrote:
> >
> >                                  Ladislav Lhotka
> >                             <[e-mail]><mailto:[e-mail]>wrote:
> >
> >                                  > Martin Bjorklund
> >                             <[e-mail]><mailto:[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"?
> >
> >
> >     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:

Again, it is *not* 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>

In this case, the prefix-string -> uri mapping is taken from the XML
namespace declaration in the XML document.


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

Do you mean instance-identifier?  If so, it is a special type that
happens to share the syntax with XPath, and the JSON syntax is defined
in RFC 7951 section 6.11.

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

In this case, the prefix-string -> uri mapping is given in the
document.


We use XPath in various different places, and each place MUST specify
the evaluation context.



/martin


> > 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
> >
> >                                  > >
> >                             [e-mail]<mailto:[e-mail]>
> >
> >                                  > >
> >                             https://www.ietf.org/mailman/listinfo/netmod
> >
> >                                  >
> >
> >                                  > --
> >
> >                                  > Ladislav Lhotka
> >
> >                                  > Head, CZ.NIC Labs
> >
> >                                  > PGP Key ID: 0xB8F92B08A9F76C67
> >
> >                                  >
> >
> >                                 
> >                             _______________________________________________
> >
> >                                  netmod mailing list
> >
> >                             [e-mail]<mailto:[e-mail]>
> >
> >                             https://www.ietf.org/mailman/listinfo/netmod
> >
> >                             _______________________________________________
> >
> >                             netmod mailing list
> >
> >                             [e-mail]<mailto:[e-mail]>
> >
> >                             https://www.ietf.org/mailman/listinfo/netmod
> >
> >             _______________________________________________
> >
> >             netmod mailing list
> >
> >             [e-mail]<mailto:[e-mail]>
> >
> >             https://www.ietf.org/mailman/listinfo/netmod
> >
> >             ..
> >
> >     .
> >
> >
> >
>