Re: [netmod] xpath expressions in JSON

[Robert Wilton <[e-mail]>]

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:

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