Re: [netmod] xpath expressions in JSON

[Martin Bjorklund <[e-mail]>]

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.

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



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