Subject: [netmod] xpath expressions in JSON

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 13:16:10 +0200 (CEST)

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.

How is this supposed to work with JSON?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Oct 2018 14:40:37 +0200

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

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 15:59:15 +0200 (CEST)

> 2. use a module name rather than a prefix in XML, too.

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.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 01:59:57 +0000

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

    > 2. use a module name rather than a prefix in XML, too.
<RR> But that means making non-backwards compatible change to the XML representation?

    
    
    .... 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.
<RR> So we need an update to RFC7951?

Regards,
Reshad.

    /martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2018 19:23:36 -0700

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

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

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

>     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 it
(with a capability URI)

> <RR> So we need an update to RFC7951?

Andy

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Oct 2018 02:46:14 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Ladislav Lhotka
发送时间: 2018年10月10日 20:41
收件人: Martin Bjorklund; [email-masked]
主题: Re: [netmod] xpath expressions in JSON

[Qin]: This has been brought up before:
https://www.ietf.org/mail-archive/web/netconf/current/msg15501.html

I would suggest #2.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Oct 2018 08:08:44 +0200

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

The thing is that XPath is "XML Path Language", so using it outside XML is
problematic.

Lada

> We should avoid making off-the-shelf implementations of standards like XPath
> unusable.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 08:39:04 +0200 (CEST)

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

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

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 08:42:42 +0200 (CEST)

> The thing is that XPath is "XML Path Language", so using it outside XML is

Not necessarily.  Section 5 of the XPath 1.0 spec defins the "data
model" where an XPath expression is applied.  We could make a formal
specification of how a YANG data tree maps to this data model (pretty
straightforward...).  I think experience from implementations over the
last 8 years show that this in fact works quite well.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 08:44:56 +0200 (CEST)

> https://www.ietf.org/mail-archive/web/netconf/current/msg15501.html

That is a slightly different problem; how to represent an
*instance-identifier* in a RESTCONF URL.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Oct 2018 02:21:29 -0700

>   /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.
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']

Andy

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 11 Oct 2018 11:43:39 +0200

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 10:46:11 +0100

On 11/10/2018 10:21, Andy Bierman wrote:
>
>
> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>     > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     >
>     > > [email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked] <mailto:[email-masked]>> wrote:
>     > >
>     > >     Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
>     > >     > Martin Bjorklund <[email-masked]
>     <mailto:[email-masked]>> 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?
>     > >
>     >
> 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
Hum, that is going to make these expressions very long, and not 
particularly human readable.

The XPath 1.0 spec that YANG using is effectively obsoleted by newer 
(much more complex) versions.  I doubt that this will be liked, but my 
view is that the longer term solution here is for a bespoke "YANG Path" 
language to be specified, closely based on XPath 1.0, but fixing some of 
the issues that we have using XPath for YANG constraints (e.g. it is 
easy to get them wrong), and removing some of stuff that isn't helpful 
(e.g. node tests, processing instructions, etc).

Thanks,
Rob

>     > >     >
>     > >     > Lada
>     > >     >
>     > >     > >
>     > >     > > How is this supposed to work with JSON?
>     > >     > >
>     > >     > >
>     > >     > > /martin
>     > >     > >
>     > >     > > _______________________________________________
>     > >     > > netmod mailing list
>     > >     > > [email-masked] <mailto:[email-masked]>
>     > >     > > https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > >     >
>     > >     > --
>     > >     > Ladislav Lhotka
>     > >     > Head, CZ.NIC Labs
>     > >     > PGP Key ID: 0xB8F92B08A9F76C67
>     > >     >
>     > >
>     > > netmod@ietf..org <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > >
>     > >
>     > > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > >
>
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 12:21:37 +0200 (CEST)

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

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 11:43:28 +0100

> I disagree.  You need an XPath implementation + custom code to set up
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:

Thanks,
Rob

> .

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 12:50:07 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> >>>> Not really. It means NETMOD WG would be creating its own special
> >>>> variant
> >>> of
> >>>> XPath.

*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

> >> the
> >> from

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 11 Oct 2018 13:00:27 +0200

>  /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']

Length is the only real problem I see with the solution. The lexical 
representation of identityref type has made a compromise accepting 
prefix instead of module name. This has its own unsolved issues but 
those could be addressed by a limitation not allowing modules with 
identical prefix statements to define homonyme data nodes and identities 
(which is not the case currently). If this is done module name can be 
replaced with prefix and the instance-identifiers will be shorter and 
encoding independent but still Xpath 1.0 compatible:

  /if:interfaces/if:interface[if:name='eth0']

Vladimir

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 11 Oct 2018 13:09:12 +0200

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

The order of the keys does not need to be alphabetical. It can be the 
order of the keys specified in the YANG module but currently there is no 
requirement for order at all.

Vladimir

>>>>      > > [email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 12:16:29 +0100

> *this* would require a custom XPath implementation.
Why?  I.e. how is this different from stating "Custom code is needed to 
connect things together"?

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

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? :-)

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 15:34:34 +0000

Hi Rob,

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

Robert Wilton <[email-masked]><mailto:[email-masked]> wrote:

Andy Bierman <[email-masked]><mailto:[email-masked]> wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <[email-masked]><mailto:[email-masked]>

wrote:

Andy Bierman <[email-masked]><mailto:[email-masked]> wrote:

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

[email-masked]<mailto:[email-masked]>>

wrote:

[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

     Ladislav Lhotka <[email-masked]><mailto:[email-masked]> wrote:

     > Martin Bjorklund <[email-masked]><mailto:[email-masked]> writes:

     > > Note the "stream-xpath-filter".  It has a prefix in the XPath

string.

     > >               o  The set of namespace declarations are those in

scope on

     > > This assumes that the encoding is XML, or at leas that the

encoding

     > I would suggest #2.

<RR> But that means making non-backwards compatible change to the XML

representation?

variant

of

XPath.

The XPath expression is normally parsed within an XML instance

document.

There are "xmlns" attributes present that map the prefix to a

namespace URI.

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.

the environment.

*this* would require a custom XPath implementation.
Why?  I.e. how is this different from stating "Custom code is needed to connect things together"?

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:

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?

Regards,
Reshad.

Thanks,
Rob

/martin

Thanks,

Rob

change this.

/martin

the

prefixes.

from

the parent

missing (no namespace).

'interface'.

/martin

Andy

              o  The set of namespace declarations has one member for

each

                 This means that in the XPath expression, the module

name

                 serves as the prefix.

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

yang:xpath1.0

     built-in.

XPath unusable.

At the very least this should be only available if the server supports

it

(with a capability URI)

Regards,

Reshad.

Andy

     /martin

     > > [email-masked]<mailto:[email-masked]>

     netmod mailing list

     [email-masked]<mailto:[email-masked]>

netmod mailing list

[email-masked]<mailto:[email-masked]>

netmod mailing list

[email-masked]<mailto:[email-masked]>

..

.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 16:56:20 +0100

Hi Reshad,

Please see RW: inline.

On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
>
> Hi Rob,
>
> *From: *netmod <[email-masked]> on behalf of "Robert Wilton 
> -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
> *Date: *Thursday, October 11, 2018 at 7:17 AM
> *To: *Martin Bjorklund <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] xpath expressions in JSON
>
>     Robert Wilton <[email-masked]><mailto:[email-masked]>wrote:
>
>             Andy Bierman
>             <[email-masked]><mailto:[email-masked]>wrote:
>
>                     Andy Bierman
>                     <[email-masked]><mailto:[email-masked]>wrote:
>
>                             [email-masked]<mailto:[email-masked]>on
>                             behalf of
>                             [email-masked]<mailto:[email-masked]>> wrote:
>
>                                  Ladislav Lhotka
>                             <[email-masked]><mailto:[email-masked]>wrote:
>
>                                  > Martin Bjorklund
>                             <[email-masked]><mailto:[email-masked]>writes:
>
>                                  >
>
>                                  > > Hi,
>
>                                  > >
>
>                                  > > Note the "stream-xpath-filter". 
>                             It has a prefix in the XPath
>
>                             string.
>
>                                  > >               o  The set of
>                             namespace declarations are those in
>
>                             scope on
>
>                                  > >                  the
>                                  > > This assumes that the encoding is
>                             XML, or at leas that the
>
>                     encoding
>
>                                  > 1. have different representations
>                             of this value in XML and JSON,
>
>                                  >    analogically to instance
>                             indentifiers (sec. 6.11 in RFC 7951).
>
>                                  >
>
>                         "ietf-interfaces" ->
>                     "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
>                         "ietf-ip"         ->
>              "ietf-interfaces" ->
>         "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
> 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.
>
RW:

This is already looks like 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>

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

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 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? :-)
>
RFC 8040.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 18:11:50 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> >>>>> [email-masked]>

B/c the specification of XPath allows you to (actually, *requires* you
to) construct the set of prefix strings to url mappings.

This is "custom code to connect things".

But changing the syntax means changin the specification.

> introducing yet another Xpath format to YANG.

I agree that it is very verbose.  But do not mix XPath expressions in
leaf values (which is what this thread is about) with
instance-identfiers.

>       "namespace" statement in the YANG module.

Perfect!  It seems the authors of 8040 thought of this ;-)

> wrong, or otherwise what am I missing? :-)

It seems the example is wrong!

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 18:16:52 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> > *From: *netmod <[email-masked]> on behalf of "Robert Wilton -X
> > *(rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>

Again, it is *not* another format!

> 
> Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241
> sec 8.9.5.1
> 

In this case, the prefix-string -> uri mapping is taken from the XML
namespace declaration in the XML document.

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Oct 2018 09:25:20 -0700

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

> -X
> > >                     <[email-masked]><mailto:[email-masked]
> >wrote:
> > >
> > >                             <[email-masked]><mailto:[email-masked]
> >wrote:
> > >
> > >                                  > Martin Bjorklund
> > >                             <[email-masked]><mailto:[email-masked]
> >writes:
> > >
> > >                                  >
> > >
> > >                                  > > Hi,
> > >
> > >                                  > >
> > >
> > >                             'stream-xpath-filter' leaf element.
> > >
> > >                                  > >
> > >

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.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Oct 2018 17:45:31 +0100

> But changing the syntax means changin the specification.
Not really.

It would just mean that the filter value is not an "Xpath" expression.  
It is a more a concise string that can be expanded into an Xpath expression.

> leaf values (which is what this thread is about) with
OK, but ultimately:
- these are both leaf values.
- they both identify nodes in a YANG datastore.
- the fact that their format is somewhat subtlety different will catch 
people out.

> Perfect!  It seems the authors of 8040 thought of this ;-)
OK, what you propose would at least be consistent with how the XPath is 
formed in sec 8040, 4.8.4?

I can live with that.  But still strongly think that WG should think of 
trying to move YANG on from Xpath 1.0.

> It seems the example is wrong!
Please can you check section 8040, 8.3.6.  Are all the examples wrong?

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Oct 2018 09:52:49 -0700

On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <[email-masked]> wrote:

> ....

I do not agree YANG should change any statements where XPath is being used.
(Note that leafs like the filter are free to use whatever data type they
want, including yang:xpath1.0).

The WG is on the right track already wrt/ XPath by creating custom XPath
functions
like 'deref' that simplify syntax or extend functionality.

Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 11 Oct 2018 18:12:18 +0000

Hi Rob,

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Thursday, October 11, 2018 at 11:56 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] xpath expressions in JSON

<trimmed>

<RR2> B.3.6, got it. Was looking for 8.3.6, that’s why didn’t find it.

Regards,
Reshad.

Thanks,
Rob

Regards,
Reshad.

Thanks,
Rob

/martin

Thanks,

Rob

change this.

/martin

the

prefixes.

from

the parent

missing (no namespace).

'interface'.

/martin

Andy

each

name

                 serves as the prefix.

yang:xpath1.0

     built-in.

XPath unusable.

it

(with a capability URI)

Regards,

Reshad.

Andy

     /martin

     netmod mailing list

netmod mailing list

netmod mailing list

..

.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 12 Oct 2018 10:37:27 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> >>>>>>>>>        > >               o The set of namespace declarations are
> >>>>>>>>>        > >               those
> >>>>>>>>>        > >               in
> >>>>>>>>> scope on
> It would just mean that the filter value is not an "Xpath"
> expression.  It is a more a concise string that can be expanded into
> an Xpath expression.
> 
> >

Agreed.

We already have:

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes

So an alternative could be to use different encodings for
"stream-xpath-filter" as well, depending on if it is XML or JSON.

So, we could do in SN:

             o  If the node is encoded in XML, the set of namespace
                declarations are those in scope on the
                'stream-xpath-filter' leaf element.

             o  If the node is encoded in JSON, 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.

This is far from perfect, but at least the format is consistent within
each encoding.  One problem is that it is unclear how to handle other
encodings.

If we do this, we'll set a precedence for future models.

Now, suppose we have a module "ex-foo" with namespace
"urn:example:foo".  If an XML client writes:

   <example-expr xmlns:f="urn:example:foo">
     /f:bar/f:baz
   </example-expr>

a JSON will read this node as:

   "example-expr": "/ex-foo:bar/ex-foo:baz"

[This context-dependent encoding that we have for a couple of types is
probably the biggest mistake in YANG]

BTW, we already have this issue w/ NACM's node-instance-identifier.
It is highly unclear what a JSON client is supposed to see if it reads
NACM rules with node-instance-identifiers.

> OK, what you propose would at least be consistent with how the XPath
> is formed in sec 8040, 4.8.4?
> 
> I can live with that.  But still strongly think that WG should think
> of trying to move YANG on from Xpath 1.0.
> 
> >

Yes it seems so.  Except the last one.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Fri, 12 Oct 2018 10:44:31 +0100

>    o  XPath in JSON query filter uses module names as prefixes
Yes, but in the two JSON cases, the way that they use the module name 
prefixes is still different.  I.e. they differ in the required namespace 
encoding when a child element is in the same namespace it is parent, for 
an instance-identifier they MUST be excluded, for the XPath in JSON 
query filter they MUST be included.

I think that the crux of the problem is XPath is designed/specified for 
XML documents.

> each encoding.  One problem is that it is unclear how to handle other
I agree that this is a valid alternative.  I don't know whether or not I 
prefer it.  Arguably it is more consistent and doesn't cause the RFC 
7951 JSON style encoding to leech into the XML encoding.

I would expect the CBOR encoding to either define its own binary format 
for this, or follow the JSON style.

> If we do this, we'll set a precedence for future models.
Yes, this is the part that concerns me the most, that we are reinforcing 
that the format for these type of leaves can be encoding dependent.

> probably the biggest mistake in YANG]
I agree that it is far from ideal.

In an ideal world, I would like to see an encoding like the JSON 
instance identifier one (because it seems reasonably concise and simple) 
used for both instance identifiers and XPath expressions, but that would 
require us defining a replacement for XPath and is obviously out of 
scope for this particular problem.

> NACM rules with node-instance-identifiers.
I agree.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Fri, 12 Oct 2018 11:22:50 +0100

Hi Andy,

On 11/10/2018 17:52, Andy Bierman wrote:
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     ....
>
>
>             4.8.4), which also uses XPath expressions is meant to
>             work. That
>             states:
>
>     OK, what you propose would at least be consistent with how the
>     XPath is formed in sec 8040, 4.8.4?
>
>     I can live with that.  But still strongly think that WG should
>     think of trying to move YANG on from Xpath 1.0.
>
>
>
> (Note that leafs like the filter are free to use whatever data type 
> they want, including yang:xpath1.0).

OK, I think that I would be proposing either doing this as part of 
YANG.next, or perhaps as different leaf types.

>
> The WG is on the right track already wrt/ XPath by creating custom 
> XPath functions

Yes, the functions partially help.

But there are bits of Xpath expressions that are not meaningful for YANG 
(e.g. NodeType checks or processing-instruction).

The fact that NodeSets are sets rather than sequences isn't particularly 
helpful (fixed in future versions of XPath).

E.g. if I wanted to check that a particular YANG boolean leaf is true 
then I might write "enabled = true" ... which is valid XPath, but 
probably doesn't do what most people expect ...
When they realize that is wrong, perhaps they will try "enabled = 
true()" instead ... which is also valid XPath, but still probably won't 
do what they expect ...
Instead they have to do 'enabled = "true"'.

And then what about comparisons for 64 bit numbers that don't work properly?

So, it seems like there are quite a lots of gotchas when using XPath for 
YANG, and it is far from an ideal language for expressing configuration 
constraints.

If YANG adoption increases, and if folks start putting more validation 
constrains into the model then I hope that we will end up with a better 
language for expressing those constraints.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Oct 2018 09:09:21 -0700

On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton <[email-masked]> wrote:

> E.g. if I wanted to check that a particular YANG boolean leaf is true then
> I might write "enabled = true" ... which is valid XPath, but probably
> doesn't do what most people expect ...
> When they realize that is wrong, perhaps they will try "enabled = true()"
> instead ... which is also valid XPath, but still probably won't do what
> they expect ...

There are parts of XPath that are not used and most people are unaware
XPath even has
those details. Not a real problem.

There is usually a high cost to pay for instability. IMO we have already
seen that with the churn
that NMDA has caused. Training people over again has a cost.  Confusing
people by having
6 or 7 different path language variants that mostly look the same has a
cost.

I guess we will have this debate for real if YANG 2.0 is ever done

Thanks,
Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 12 Oct 2018 17:34:34 +0000

On 2018-10-12, 4:37 AM, "netmod on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    Agreed.
    
    We already have:

    
    So, we could do in SN:

    This is far from perfect, but at least the format is consistent within
    each encoding.  
<RR> I'd be ok with that since it's consistent with what's already done for other "types". So the stream-xpath-filter in A.1.1 of RESTCONF-notif would be along the lines of "/ex-foo:foo/".

One problem is that it is unclear how to handle other
    encodings.

    

    
    
    Yes it seems so.  Except the last one.
<RR> I'm volunteering Rob to submit the errata (

Regards,
Reshad.    
    
    /martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Oct 2018 16:25:48 +0200

> last 8 years show that this in fact works quite well.

Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.

This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.

Lada

---

From: Vladimir Vassilev <[email-masked]>
Date: Mon, 15 Oct 2018 21:53:28 +0200

> are ordered, whereas in YANG 'foo[1]' may give unpredictable results.

Not all XPath expressions map to something meaningful in the context of 
YANG data.  However a subset of them do.

IMO introducing yang:ypath1.0 makes sense but it is practical to define 
it as a subset of yang:xpath1.0. Martins proposal 2) for an encoding 
independent solution where the prefixes are restricted to be module 
names works. Proposal 1) seems to be a step back clogging YANG with 
encoding specific details.

Vladimir

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Oct 2018 12:30:36 +0200 (CEST)

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

Alternative A:
--------------

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  <stream-xpath-filter
      xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
      xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
    /if:interfaces/if:interface/ip:ipv4
  </stream-xpath-filter>

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"

Alternative B:
--------------

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

    o  The set of namespace

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
     expressions, such as get-config filter and nacm rules.

Example in XML:

  <stream-xpath-filter>
    /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
  </stream-xpath-filter>

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"

My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Oct 2018 12:55:36 +0200

>   o  XPath in JSON query filter uses module names as prefixes

Actually, schema mount uses yet another approach - prefix/namespace mapping is a
part of the data itself:

        +--ro namespace* [prefix]
        |  +--ro prefix    yang:yang-identifier
        |  +--ro uri?      inet:uri

It could work here, too.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 18 Oct 2018 12:10:41 +0100

Given where we are, I also agree that A is the better choice.

I would also like to have a context-independent encoding of all YANG 
types in the future.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 18 Oct 2018 13:17:53 +0000

We can't time travel and as you mentioned option A has consistency within each encoding, so I'm also for option A. 

Regards,
Reshad.

On 2018-10-18, 6:30 AM, "netmod on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    To summarize:
    
    We already have

    Alternative A:
    --------------

    We would do in SN:

    

    
    Example in XML:
    
      <stream-xpath-filter
    
    Example in JSON:
    
      "stream-xpath-filter":

    Alternative B:
    --------------

    We would do in SN:
    
        o  The set of namespace

    
    Example in XML:
    
      <stream-xpath-filter>
    
    Example in JSON:
    
      "stream-xpath-filter":

    
    
    /martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 18 Oct 2018 19:42:00 +0200

Hi,

Seems this discussion affects 10 draft modules using the xpath1.0 type. 
The proposed boilerplate description text that was not added to some RFC 
modules like [email-masked]

should be as consistent as possible (or skipped based on the 
ietf-netconf-monitoring precedent) until a better alternative is 
available. Here is an example of a better alternative.

    typedef ypath1.0 {
     type xpath1.0;
     description
      "This type represents subset of XPATH 1.0 expressions
       that apply to a data tree conforming to a YANG model.

       Each encoding should allow conversion to an encoding
       independent lexical representation where data node
       prefixes are resolved to and substituted with module
       names.

       When a schema node is defined that uses this type, the
       description of the schema node MUST specify the
       context in which the expression is evaluated if it
       is different from the default context.

       The default context is as follows:

         o  The set of variable bindings is empty.

         o  The function library is the core function library, and
            the XPath functions defined in section 10 in RFC 7950.

         o  The context node is the leaf node.

       ";
     reference
      "XPATH: XML Path Language (XPath) Version 1.0";
   }

That said I do not object to short-term application of alternative A as 
long as a long-term solution is on its way for future modules.

Vladimir

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Oct 2018 12:45:44 -0700

Hi,

I strongly agree that a new data type is needed (ypath1.0 or just ypath is
fine)
Adding new semantics or requirements to published data types is
unacceptable.

Also, we must get the type and module containing the data type right on the
first try.
No moving it later because the import looks bad. That said, a "quick
6991-bis" is unrealistic,
and a multi-year 6991-bis is unhelpful.

Should there be a canonical format, based on module-names as prefixes?
Consider how to compare 2 values using this data type.

Andy

On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
[email-masked]> wrote:

> ietf-netconf-monitoring precedent) until a better alternative is available.
> Here is an example of a better alternative.
>
>    typedef ypath1.0 {
>     type xpath1.0;
>     description

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Oct 2018 21:50:41 +0200

On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:

> 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.

https://datatracker.ietf.org/doc/rfc6991/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Oct 2018 21:58:26 +0200 (CEST)

> Consider how to compare 2 values using this data type.

Ok.  So which alternative do you prefer for stream-xpath-filter, which
is supposed to work also for JSON?  The current definition doesn't
work for JSON.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Oct 2018 12:58:33 -0700

> https://datatracker.ietf.org/doc/rfc6991/

Are you suggesting that because it only took  11 months last time we will
not keep adding "1 more thing" over and over for 24+ months (like some
other work items)?
If so, I hope you are right.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Oct 2018 13:28:45 -0700

> is supposed to work also for JSON?  The current definition doesn't

I don't like calling it xpath when it is not XPath any more.
It should be as clear as possible to readers and designers that xpath
means XPath and ypath is not XPath.

I would prefer a new encoding that allows the parent node module-name to be
used somehow,
consistent with the JSON encoding used now.

Perhaps each absolute-path expression starts with a module-name step and
relative-path
expressions assume the module name of the context node if there is no
module-name.

Neither alternative below is a good long-term solution.

The old problems come up again:

  Client A writes the /foo node in XML.
  Client B reads the /foo node returned in JSON

Which format is returned? Does the server magically convert the value for
each encoding type?
If we bother to fix this problem at all, then we should get rid of reliance
on prefix to namespace mappings.

Andy

> available.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Oct 2018 22:31:34 +0200

> not keep adding "1 more thing" over and over for 24+ months (like some

There is no guarantee but as long as we start with the assumption that
what we do will be slow, we should not be surprised that things are
actually slow. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Oct 2018 22:32:48 +0200 (CEST)

> I don't like calling it xpath when it is not XPath any more.

But stream-xpath-filter *is* XPath.  The alternative solutions differ
only in how the prefix mapping is defined.

> Neither alternative below is a good long-term solution.

Agreed, but we need to find a solution for stream-xpath-filter, or
else we should remove it from SN.

> Which format is returned? Does the server magically convert the value for

Yes, just like it does with i-i and identityref.

> on prefix to namespace mappings.

Long-term, yes!

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Oct 2018 14:05:28 -0700

On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund <[email-masked]> wrote:

> > > > I strongly agree that a new data type is needed (ypath1.0 or just
> ypath
> > > is
> > > > fine)
> > > > Also, we must get the type and module containing the data type right
> on
> > > the
> > > > first try.

I don't think it should be called XPath if module-names are used as
prefixes.
Alternative A using a special data type is the least objectionable I guess

Andy

> > > > > The proposed boilerplate description text that was not added to
> some
> > > RFC

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Oct 2018 10:11:37 +0200

>   o  XPath in JSON query filter uses module names as prefixes

Is "supported" the same as "implemented", or something else?

> Con: we keep using context-depending encodings.

  Con: XPath expressions in JSON can get pretty long (I assume it's not
  just an instance identifier but may contain predicates etc.). We
  cannot use the trick with the default namespace as in YANG, so all
  data node names will have to carry the prefix.

>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"

I would suggest to consider declaring prefixes & namespaces explicitly
in the data, as in the schema mount document. It is independent of
encoding and the expressions can be kept short. In fact, one of the
namespaces can be declared as default, so this use of XPath would then
be very similar to YANG.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2018 14:56:05 +0200 (CEST)

> Is "supported" the same as "implemented", or something else?

It should be "implemented".

>   data node names will have to carry the prefix.

Yes.

> namespaces can be declared as default, so this use of XPath would then

Ok, so this is another alternative that works today, and achieves the
goal of being encoding-independent.  It is still context-dependent
though.

BTW, when used in filters, it is nice to let an unprefixed name to
match any namespace; i.e., treat "foo" as syntactic sugar for
"local-name(.) = 'foo'".  ("*:foo" is not legal...)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2018 15:11:30 +0200

> goal of being encoding-independent.  It is still context-dependent

Yes, every module that uses XPath in data will have to deal with this. There may
potentially be multiple independent prefix declarations (this is actually a
con). 

> "local-name(.) = 'foo'".  ("*:foo" is not legal...)

Hmm, I think this is a bad idea because it departs even further from the
original XPath semantics. Such chameleon names should IMO be pretty rare, and if
they are needed, local-name() is always available.

Lada

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Oct 2018 02:12:00 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Ladislav Lhotka
发送时间: 2018年10月22日 21:12
收件人: Martin Bjorklund
抄送: [email-masked]
主题: Re: [netmod] xpath expressions in JSON

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> > > Going back to the most urgent issue, what is this WG's 
> > > recommendation for the subscribed-notifications draft in NETCONF 
> > > wrt/ their usage of
> > > Use different encodings for "stream-xpath-filter" as well, 
> > > depending on if it is XML or JSON.
> > >
> > > We would do in SN:
> > >
> > I would suggest to consider declaring prefixes & namespaces 
> > explicitly in the data, as in the schema mount document. It is 
> > independent of encoding and the expressions can be kept short. In 
> > fact, one of the namespaces can be declared as default, so this use 
> > of XPath would then be very similar to YANG.
> 

Yes, every module that uses XPath in data will have to deal with this. There may potentially be multiple independent prefix declarations (this is actually a con). 

> "local-name(.) = 'foo'".  ("*:foo" is not legal...)

Hmm, I think this is a bad idea because it departs even further from the original XPath semantics. Such chameleon names should IMO be pretty rare, and if they are needed, local-name() is always available.

[Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the below guideline is relevant.
"
The "local-name" function SHOULD NOT be used to reference local names
   outside of the YANG module that defines the must or when expression
   containing the "local-name" function.  Example of a "local-name"
   function that should not be used:

      /*[local-name()='foo']

"
Lada

> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > > (This said, I would like to have a context-independent encoding of 
> > > all YANG types in the future.  But not now.)
> > >
> > >
> > >
> > >
> > > /martin
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Oct 2018 08:42:54 +0200 (CEST)

>    function that should not be used:

This guideline is for must/when expressions *within* YANG modules.

I'm talking about a different use case, namely filtering.  It is
pretty convenient for users to send a filter:

  /interfaces/interface[name='eth0'/ipv4

and get back what they expect.  Even in the rare case of local name
clashes, this filter works and gives back what was expected (+
additional nodes).

I have no plans on writing up this as a proposal; I'm just pointing
out that when XPath is used in filters, this is convenient.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Oct 2018 09:36:55 +0200

>   /interfaces/interface[name='eth0'/ipv4

This is impossible if we want to call it XPath. With an explicit
namespace/prefix declaration, for example

  "namespace": [
    {
      "prefix": "if",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
      "default": true
    },
    {
      "prefix": "ip",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
    }
  ]

it would be

  /interfaces/interface[name='eth0']/ip:ipv4

which is not too bad either.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Oct 2018 10:29:50 +0200 (CEST)

> which is not too bad either.

Well, "ncc myhost --get -x /interfaces/interface[name='eth0']/ipv4" is
a one-liner; if I also have to specify the namespace list for every
filter, it suddenly is not that convenient.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Oct 2018 10:35:49 +0200

On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> > >> Yes, every module that uses XPath in data will have to deal with this.
> There may potentially be multiple independent prefix declarations (this is
> actually a con). 
> 
> > >> 
> 
> > >> > 
> 
> original XPath semantics. Such chameleon names should IMO be pretty rare, and
> if they are needed, local-name() is always available.
> 
> > >> 
> 

But this is an UI issue. I am not against any aid provided by client tools, what
I am talking about is the "oficial" lexical representation of that data type,
that is also exchanged in protocols. The above expression breaks XPath rules.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Oct 2018 10:42:48 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> that is also exchanged in protocols.

> The above expression breaks XPath rules.

This I agree with!

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 23 Oct 2018 10:10:48 +0100

> which is not too bad either.
This looks verbose to me.

I would still prefer using separate encodings for XML vs JSON/CBOR 
(alternative A) in the short term.

Longer term, I think that we should look at something similar to the 
JSON path encoding scheme.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Oct 2018 11:20:54 +0200

On Tue, 2018-10-23 at 10:10 +0100, Robert Wilton wrote:
> > > > There may potentially be multiple independent prefix declarations (this
> > > > is actually a con).
> > > > 
> > > > original XPath semantics. Such chameleon names should IMO be pretty
> > > > rare, and if they are needed, local-name() is always available.
> > > > 

Note that the namespace information needn't be sent along with every XPath
expression as it would probably be the case in the XML encoding of option A.
Only if a new namespace is being used, the "namespace" list has to be updated. 

> (alternative A) in the short term.

Sure, this is another decent option.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Oct 2018 11:28:00 +0200

> Only if a new namespace is being used, the "namespace" list has to be updated. 

Can we pre-populate the context with namespaces, for example,
controlled via an extension of yang library? Perhaps we can simply
pre-polutate contexts with all module names? Yes, I know this makes
xpath expressions rather verbose but on the other hand it takes away
guesswork and (client) tools may do expansion of an unprefixed
expression into a proper namespace prefixed expression.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 23 Oct 2018 10:39:22 +0100

Hi Juergen,

Is this the same as Martin's alternative B proposed previously 
(attached)?  Or are you suggesting a different alternative?

Thanks,
Rob

Subject: Re: [netmod] xpath expressions in JSON
From: Martin Bjorklund <[email-masked]>
To: [email-masked]
Date: Thu, 18 Oct 2018 12:30:36 +0200 (CEST)
List-Id: NETMOD WG list <netmod.ietf.org>

Hi,

To summarize:

We already have

Alternative A:
--------------

We would do in SN:

Example in XML:

  <stream-xpath-filter

Example in JSON:

  "stream-xpath-filter":

Alternative B:
--------------

We would do in SN:

    o  The set of namespace

Example in XML:

  <stream-xpath-filter>

Example in JSON:

  "stream-xpath-filter":

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Oct 2018 12:16:30 +0200

On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> Is this the same as Martin's alternative B proposed previously (attached)? 
> Or are you suggesting a different alternative?
>

Likely the same, but I admit that I do not understand Martin's
comment:

If the context has ietf-interfaces pre-populated and you receive
if:ietf-interfaces with proper XML namespace bindings, one could add
the prefix if to the namespace declarations. One might even use (if
the server signals that it supports prepopulated namespaces) the
module name prefixed xpath expressions in say get-data.

The only downside really is the verbosity but I value compatibility
with xpath and no ambiguity or corner cases where things can clash
higher than compactness. And a client that is capable to parse xpath
and yang-library aware may do the expansion locally or if we work out
the details, a server may signal its ability to do the expansion as
well (not sure though that all this is effort well invested since N
different ways to send around xpath expressions increases costs on all
sides and is asking for interoperability problems. Hence, I rather go
with longish xpath expressions for the sake of simplicity and
interoperability.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Oct 2018 12:28:13 +0200

> module name prefixed xpath expressions in say get-data.

This may be the best option: the "verbose" prefix/namespace bindings will be
available in all encodings, which doesn't prevent users of the XML encoding to
define additional ones.

I would suggest to extend the definition of the "xpath1.0" type with the
corresponding specification of the default XPath context.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Oct 2018 15:42:35 +0200 (CEST)

> available in all encodings, which doesn't prevent users of the XML encoding to

Yes, and we can define a canonical format (with module names), and it
is backwards compatible.  The only problem is verbosity, but I think
that is unavoidable.

> corresponding specification of the default XPath context.

Yes, something for 6991bis.

Meanwhile, for SN, we can add this already there for stream-xpath-filter.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Oct 2018 16:00:08 +0200

> Meanwhile, for SN, we can add this already there for stream-xpath-filter.

I am not sure whether a new type definition is needed or just some
clarification of the current xpath1.0 definition. Perhaps a new
definition plus deprecation of the xpath1.0 definition is the right
thing to do. I have added this to my list of possible changes to
RFC 6991.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Oct 2018 22:16:12 +0000

I submitted yang-next issue #55 to track the long-term solution.

https://github.com/netmod-wg/yang-next/issues/55

K.

-----Original Message-----
From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Reply-To: Juergen Schoenwaelder <[email-masked]>
Date: Tuesday, October 23, 2018 at 10:00 AM
To: Martin Bjorklund <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] xpath expressions in JSON

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=OYG_fxffwCJOWueATMe9b73VMEAPJoZW-LckDCww-zQ&s=h4I_afqQxv59YjCpmQoMSMEaFSCINuosp84DTFIgYS8&e=>

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=OYG_fxffwCJOWueATMe9b73VMEAPJoZW-LckDCww-zQ&s=bNpVmLtw6crkmxB3FFeBC8GcqN3CcJ92ug2_hCFD3j0&e=