Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev <[e-mail]>]

On 10/11/18 8:39 AM, Martin Bjorklund 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

+1. This is one of the two necessary changes to make the 
instance-identifier type canonical. Proposed changes RFC 7950:

OLD:

9.13.2.  Lexical Representation

    An instance-identifier value is lexically represented as a string.
    All node names in an instance-identifier value MUST be qualified with
    explicit namespace prefixes, and these prefixes MUST be declared in
    the XML namespace scope in the instance-identifier's XML element.

    Any prefixes used in the encoding are local to each instance
    encoding.  This means that the same instance-identifier may be
    encoded differently by different implementations.

9.13.3.  Canonical Form

    Since the lexical form depends on the XML context in which the value
    occurs, this type does not have a canonical form.

NEW:

9.13.2.  Lexical Representation

    An instance-identifier value is lexically represented as a string.
    All node names in an instance-identifier value MUST be qualified with
    explicit namespace prefixes where the module name is used as prefix.

    All predicates must appear in alphabetical order.


9.13.3.  Canonical Form

    Since the lexical form is encoding independent and tere is prescribed

    alphabetical order of the predicates the type has a canonical form.


Vladimir


>
>
>
>
> /martin
>
>
>>
>>>      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