Re: [netmod] xpath expressions in JSON

[Robert Wilton <[e-mail]>]

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"

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