Re: [netmod] xpath expressions in JSON

"Reshad Rahman (rrahman)" <> Thu, 11 October 2018 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69B66130DF3 for <>; Thu, 11 Oct 2018 08:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.49
X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bf7rI3mtczKW for <>; Thu, 11 Oct 2018 08:34:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EB43130E7C for <>; Thu, 11 Oct 2018 08:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=68264; q=dns/txt; s=iport; t=1539272077; x=1540481677; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EzFioOiZW9Tb9gYkL5sWcCEU0A5ZGd4tME4mF0+uJSc=; b=ex6+DDsPiX3CGRtPIUew4FGFS9DIDKzivtPXNMZ3KCXS2qC/Y0eYvYCX v5FtWxxMXV3Ur6di0c7woqIh5T6i+D944I1JIiA/qveRBRR8asjTx7Ch/ dkunYlCNpRm5VybwBlzaxB4gFU+m0OCBSAqniTmGC3vNW8gWOAckc05MN Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208,217";a="246901717"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 15:34:35 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9BFYZTG032076 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2018 15:34:35 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 10:34:35 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 11 Oct 2018 10:34:34 -0500
From: "Reshad Rahman (rrahman)" <>
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <>, Martin Bjorklund <>
CC: "" <>
Thread-Topic: [netmod] xpath expressions in JSON
Date: Thu, 11 Oct 2018 15:34:34 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BE8F576F2A5644D885546576B9CDB0F8ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netmod] xpath expressions in JSON
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2018 15:34:40 -0000

Hi Rob,

From: netmod <> on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <>
Date: Thursday, October 11, 2018 at 7:17 AM
To: Martin Bjorklund <>
Cc: "" <>
Subject: Re: [netmod] xpath expressions in JSON

On 11/10/2018 11:50, Martin Bjorklund wrote:

Robert Wilton <><> wrote:

On 11/10/2018 11:21, Martin Bjorklund wrote:

Andy Bierman <><> wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <><>


Andy Bierman <><> wrote:

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <<>>


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <<> on behalf of<>> wrote:

     Ladislav Lhotka <><> wrote:

     > Martin Bjorklund <><> 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


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


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


Not really. It means NETMOD WG would be creating its own special




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


The XPath expression is normally parsed within an XML instance


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


as a module name and magically find the namespace URI for the module


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:


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:


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.

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?






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.


A normal XPath implementation will not find any namespace mapping for



An XPath expression has no concept of the "current module" inherited


the parent

like the JSON encoding. This is problematic for predicates


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


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:




     Hmm, so you mean change the leaf "stream-xpath-filter" to say:

              o  The set of namespace declarations has one member for


                 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


                 serves as the prefix.

     .... and then also give an example of this.

     This is probably what we need to do in all places where


     is used, going forward.  Maybe even define a new type

     yang:xpath1.0-2 (name?) with the set of namespace declarations


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


(with a capability URI)

<RR> So we need an update to RFC7951?






     > Lada


     > >

     > > How is this supposed to work with JSON?

     > >

     > >

     > > /martin

     > >

     > > _______________________________________________

     > > netmod mailing list

     > ><>

     > >


     > --

     > Ladislav Lhotka

     > Head, CZ.NIC Labs

     > PGP Key ID: 0xB8F92B08A9F76C67



     netmod mailing list<>


netmod mailing list<>


netmod mailing list<>