Re: [netmod] xpath expressions in JSON

[Andy Bierman <[e-mail]>]

On Thu, Oct 11, 2018 at 9:16 AM, Martin Bjorklund <[e-mail]> wrote:

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

You are right.
Our custom XPath code needs to be told to get prefix mappings from XML or
YANG import-stmts
already, so 1 more internal mapping directly to module name is not going to
require
any significant changes to XPath processing.

More importantly, it does not require any redefinition of the XPath
standard.


>
>
> /martin
>

Andy


>
>
> > > 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
> > >
> > >             ..
> > >
> > >     .
> > >
> > >
> > >
> >
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>