Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

On Tue, Oct 23, 2018 at 03:42:35PM +0200, Martin Bjorklund wrote:

> > I would suggest to extend the definition of the "xpath1.0" type with the
> > corresponding specification of the default XPath context.
> 
> Yes, something for 6991bis.
> 
> 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> > 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:
> > 
> >   Con: in XML, this leaf is treated differently from other XPath
> >expressions, such as get-config filter and nacm rules.
> > 
> > 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.
> 
> 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.

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.

> I would suggest to extend the definition of the "xpath1.0" type with the
> 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



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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> 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:
> 
>   Con: in XML, this leaf is treated differently from other XPath
>expressions, such as get-config filter and nacm rules.
> 
> 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.

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

> 
> 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
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

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:

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

Hi Juergen,

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


Thanks,
Rob


On 23/10/2018 10:28, Juergen Schoenwaelder wrote:

On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:

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.


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



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

  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


Alternative A:
--

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

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

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:

  
/if:interfaces/if:interface/ip:ipv4
  

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

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:

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
..

--- End Message ---
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:
> 
> 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. 
>

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Tue, 2018-10-23 at 10:10 +0100, Robert Wilton wrote:
> 
> On 23/10/2018 08:36, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Qin Wu  wrote:
> > > > -邮件原件-
> > > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> > > > 发送时间: 2018年10月22日 21:12
> > > > 收件人: Martin Bjorklund
> > > > 抄送: netmod@ietf.org
> > > > 主题: Re: [netmod] xpath expressions in JSON
> > > > 
> > > > On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> > > > > Ladislav Lhotka  wrote:
> > > > > > Martin Bjorklund  writes:
> > > > > > 
> > > > > > > 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
> > > > > > > 
> > > > > > >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
> > > > > > > 
> > > > > > > 
> > > > > > > Alternative A:
> > > > > > > --
> > > > > > > 
> > > > > > > Use different encodings for "stream-xpath-filter" as well,
> > > > > > > depending on if it is XML or JSON.
> > > > > > > 
> > > > > > > We would 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
> > > > > > Is "supported" the same as "implemented", or something else?
> > > > > It should be "implemented".
> > > > > 
> > > > > > > the YANG module name and the namespace is as defined
> > > > > > > by the "namespace" statement in the YANG module.
> > > > > > > 
> > > > > > > Pro: the format is consistent within each encoding.
> > > > > > > 
> > > > > > > Con: unclear how to handle other encodings.
> > > > > > > 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.
> > > > > Yes.
> > > > > 
> > > > > > > We could probably add that CBOR uses the same representation as
> > > > > > > JSON.
> > > > > > > 
> > > > > > > Example in XML:
> > > > > > > 
> > > > > > > > > > > > >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
> > > > > > >
> > > > > > > 
> > > > > > > Example in JSON:
> > > > > > > 
> > > > > > >"stream-xpath-filter":
> > > > > > >  "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
&g

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

On 23/10/2018 08:36, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Qin Wu  wrote:

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

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:

Ladislav Lhotka  wrote:

Martin Bjorklund  writes:


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

   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


Alternative A:
--

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

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

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

It should be "implemented".


the YANG module name and the namespace is as defined
by the "namespace" statement in the YANG module.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
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.

Yes.


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

Example in XML:

   
 /if:interfaces/if:interface/ip:ipv4
   

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

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:

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

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.

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.

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

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


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

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

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

This is impossible if we want to call it XPath. With an explicit
names

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund  writes:
> > 
> > > 
> > 
> > > > Qin Wu  wrote:
> > 
> > > >> -邮件原件-
> > 
> > > >> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> > 
> > > >> 发送时间: 2018年10月22日 21:12
> > 
> > > >> 收件人: Martin Bjorklund
> > 
> > > >> 抄送: netmod@ietf.org
> > 
> > > >> 主题: Re: [netmod] xpath expressions in JSON
> > 
> > > >> 
> > 
> > > >> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> > 
> > > >> > Ladislav Lhotka  wrote:
> > 
> > > >> > > Martin Bjorklund  writes:
> > 
> > > >> > > 
> > 
> > > >> > > > 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
> > 
> > > >> > > >
> > 
> > > >> > > >   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
> > 
> > > >> > > >
> > 
> > > >> > > >
> > 
> > > >> > > > Alternative A:
> > 
> > > >> > > > --
> > 
> > > >> > > >
> > 
> > > >> > > > Use different encodings for "stream-xpath-filter" as well, 
> > 
> > > >> > > > depending on if it is XML or JSON.
> > 
> > > >> > > >
> > 
> > > >> > > > We would 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
> > 
> > > >> > > 
> > 
> > > >> > > Is "supported" the same as "implemented", or something else?
> > 
> > > >> > 
> > 
> > > >> > It should be "implemented".
> > 
> > > >> > 
> > 
> > > >> > > >the YANG module name and the namespace is as defined
> > 
> > > >> > > >by the "namespace" statement in the YANG module.
> > 
> > > >> > > >
> > 
> > > >> > > > Pro: the format is consistent within each encoding.
> > 
> > > >> > > >
> > 
> > > >> > > > Con: unclear how to handle other encodings.
> > 
> > > >> > > > 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 wi

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> 
> > 
> 
> > > Qin Wu  wrote:
> 
> > >> -邮件原件-
> 
> > >> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> 
> > >> 发送时间: 2018年10月22日 21:12
> 
> > >> 收件人: Martin Bjorklund
> 
> > >> 抄送: netmod@ietf.org
> 
> > >> 主题: Re: [netmod] xpath expressions in JSON
> 
> > >> 
> 
> > >> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> 
> > >> > Ladislav Lhotka  wrote:
> 
> > >> > > Martin Bjorklund  writes:
> 
> > >> > > 
> 
> > >> > > > 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
> 
> > >> > > >
> 
> > >> > > >   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
> 
> > >> > > >
> 
> > >> > > >
> 
> > >> > > > Alternative A:
> 
> > >> > > > --
> 
> > >> > > >
> 
> > >> > > > Use different encodings for "stream-xpath-filter" as well, 
> 
> > >> > > > depending on if it is XML or JSON.
> 
> > >> > > >
> 
> > >> > > > We would 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
> 
> > >> > > 
> 
> > >> > > Is "supported" the same as "implemented", or something else?
> 
> > >> > 
> 
> > >> > It should be "implemented".
> 
> > >> > 
> 
> > >> > > >the YANG module name and the namespace is as defined
> 
> > >> > > >by the "namespace" statement in the YANG module.
> 
> > >> > > >
> 
> > >> > > > Pro: the format is consistent within each encoding.
> 
> > >> > > >
> 
> > >> > > > Con: unclear how to handle other encodings.
> 
> > >> > > > 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.
> 
> > >> > 
> 
> > >> > Yes.
> 
> > >> > 
> 
> > >> > > > We could probably add that CBOR uses the same representation as
> JSON.
> 
> > >> > > >
> 
> > >> > > > Example in XML:
> 
> > >> > > >
> 
> > >> > > >
> > >> > > >   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
> 
> > >> > > >   

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Qin Wu  wrote:
> >> -邮件原件-
> >> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> >> 发送时间: 2018年10月22日 21:12
> >> 收件人: Martin Bjorklund
> >> 抄送: netmod@ietf.org
> >> 主题: Re: [netmod] xpath expressions in JSON
> >> 
> >> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> >> > Ladislav Lhotka  wrote:
> >> > > Martin Bjorklund  writes:
> >> > > 
> >> > > > 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
> >> > > >
> >> > > >   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
> >> > > >
> >> > > >
> >> > > > Alternative A:
> >> > > > --
> >> > > >
> >> > > > Use different encodings for "stream-xpath-filter" as well, 
> >> > > > depending on if it is XML or JSON.
> >> > > >
> >> > > > We would 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
> >> > > 
> >> > > Is "supported" the same as "implemented", or something else?
> >> > 
> >> > It should be "implemented".
> >> > 
> >> > > >the YANG module name and the namespace is as defined
> >> > > >by the "namespace" statement in the YANG module.
> >> > > >
> >> > > > Pro: the format is consistent within each encoding.
> >> > > >
> >> > > > Con: unclear how to handle other encodings.
> >> > > > 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.
> >> > 
> >> > Yes.
> >> > 
> >> > > > We could probably add that CBOR uses the same representation as JSON.
> >> > > >
> >> > > > Example in XML:
> >> > > >
> >> > > >>> > > >   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
> >> > > >   
> >> > > >
> >> > > > 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
> >> > > >declarations is the set of prefix and namespace pairs
> >> > > >

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Qin Wu  wrote:
>> -邮件原件-
>> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
>> 发送时间: 2018年10月22日 21:12
>> 收件人: Martin Bjorklund
>> 抄送: netmod@ietf.org
>> 主题: Re: [netmod] xpath expressions in JSON
>> 
>> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
>> > Ladislav Lhotka  wrote:
>> > > Martin Bjorklund  writes:
>> > > 
>> > > > 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
>> > > >
>> > > >   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
>> > > >
>> > > >
>> > > > Alternative A:
>> > > > --
>> > > >
>> > > > Use different encodings for "stream-xpath-filter" as well, 
>> > > > depending on if it is XML or JSON.
>> > > >
>> > > > We would 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
>> > > 
>> > > Is "supported" the same as "implemented", or something else?
>> > 
>> > It should be "implemented".
>> > 
>> > > >the YANG module name and the namespace is as defined
>> > > >by the "namespace" statement in the YANG module.
>> > > >
>> > > > Pro: the format is consistent within each encoding.
>> > > >
>> > > > Con: unclear how to handle other encodings.
>> > > > 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.
>> > 
>> > Yes.
>> > 
>> > > > We could probably add that CBOR uses the same representation as JSON.
>> > > >
>> > > > Example in XML:
>> > > >
>> > > >   > > > >   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
>> > > >   
>> > > >
>> > > > 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
>> > > >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.
>> > > >
>> > > > Pro: the format is independent from the protocol encoding
>> > > >
>> > > > Con: in XML, this leaf is treated differently from other XPath
>> > > >  expressi

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Qin Wu  wrote:
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> 发送时间: 2018年10月22日 21:12
> 收件人: Martin Bjorklund
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] xpath expressions in JSON
> 
> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund  writes:
> > > 
> > > > 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
> > > >
> > > >   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
> > > >
> > > >
> > > > Alternative A:
> > > > --
> > > >
> > > > Use different encodings for "stream-xpath-filter" as well, 
> > > > depending on if it is XML or JSON.
> > > >
> > > > We would 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
> > > 
> > > Is "supported" the same as "implemented", or something else?
> > 
> > It should be "implemented".
> > 
> > > >the YANG module name and the namespace is as defined
> > > >by the "namespace" statement in the YANG module.
> > > >
> > > > Pro: the format is consistent within each encoding.
> > > >
> > > > Con: unclear how to handle other encodings.
> > > > 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.
> > 
> > Yes.
> > 
> > > > We could probably add that CBOR uses the same representation as JSON.
> > > >
> > > > Example in XML:
> > > >
> > > >> > >   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
> > > >   
> > > >
> > > > 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
> > > >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.
> > > >
> > > > 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:
> > > >
> > > >   
> > > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> > > >   
> > > >
> > > > Example in JSON:
> > > >
> > > >   "stream-xpath-filter":
> > > > "/ietf-interfaces:interfaces/

Re: [netmod] xpath expressions in JSON

[Qin Wu]

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

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > 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
> > >
> > >   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
> > >
> > >
> > > Alternative A:
> > > --
> > >
> > > Use different encodings for "stream-xpath-filter" as well, 
> > > depending on if it is XML or JSON.
> > >
> > > We would 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
> > 
> > Is "supported" the same as "implemented", or something else?
> 
> It should be "implemented".
> 
> > >the YANG module name and the namespace is as defined
> > >by the "namespace" statement in the YANG module.
> > >
> > > Pro: the format is consistent within each encoding.
> > >
> > > Con: unclear how to handle other encodings.
> > > 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.
> 
> Yes.
> 
> > > We could probably add that CBOR uses the same representation as JSON.
> > >
> > > Example in XML:
> > >
> > >> >   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
> > >   
> > >
> > > 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
> > >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.
> > >
> > > 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:
> > >
> > >   
> > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> > >   
> > >
> > > 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.
> > 
> > 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 t

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > 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
> > >
> > >   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
> > >
> > >
> > > Alternative A:
> > > --
> > >
> > > Use different encodings for "stream-xpath-filter" as well, depending
> > > on if it is XML or JSON.
> > >
> > > We would 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
> > 
> > Is "supported" the same as "implemented", or something else?
> 
> It should be "implemented".
> 
> > >the YANG module name and the namespace is as defined
> > >by the "namespace" statement in the YANG module.
> > >
> > > Pro: the format is consistent within each encoding.
> > >
> > > Con: unclear how to handle other encodings.
> > > 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.
> 
> Yes.
> 
> > > We could probably add that CBOR uses the same representation as JSON.
> > >
> > > Example in XML:
> > >
> > >> >   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
> > >   
> > >
> > > 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
> > >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.
> > >
> > > 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:
> > >
> > >   
> > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> > >   
> > >
> > > 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.
> > 
> > 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.
> 
> Ok, so this is another alternative that works today, and achieves the
> goal of being encoding-independent.  It is still context-dependent
> though.

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

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

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

> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > > (This said, I would like to have a context-independent encoding of all
> > > YANG types in the future.  But not now.)
> > >
> > >
> > >
> > >
> > > /martin
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > 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
> >
> >   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
> >
> >
> > Alternative A:
> > --
> >
> > Use different encodings for "stream-xpath-filter" as well, depending
> > on if it is XML or JSON.
> >
> > We would 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
> 
> Is "supported" the same as "implemented", or something else?

It should be "implemented".

> >the YANG module name and the namespace is as defined
> >by the "namespace" statement in the YANG module.
> >
> > Pro: the format is consistent within each encoding.
> >
> > Con: unclear how to handle other encodings.
> > 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.

Yes.

> > We could probably add that CBOR uses the same representation as JSON.
> >
> > Example in XML:
> >
> >>   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
> >   
> >
> > 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
> >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.
> >
> > 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:
> >
> >   
> > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> >   
> >
> > 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.
> 
> 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.

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





> 
> Lada
> 
> >
> > (This said, I would like to have a context-independent encoding of all
> > YANG types in the future.  But not now.)
> >
> >
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

Martin Bjorklund  writes:

> 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
>
>   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
>
>
> Alternative A:
> --
>
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
>
> We would 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

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

>the YANG module name and the namespace is as defined
>by the "namespace" statement in the YANG module.
>
> Pro: the format is consistent within each encoding.
>
> Con: unclear how to handle other encodings.
> 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.

>
> We could probably add that CBOR uses the same representation as JSON.
>
> Example in XML:
>
>  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
>   
>
> 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
>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.
>
> 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:
>
>   
> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   
>
> 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.

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

>
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
>
>
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > 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.
> > >
> > > 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.
> > >
> > >
> >
> > 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.
>


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


> > 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.
>
> Agreed, but we need to find a solution for stream-xpath-filter, or
> else we should remove it from SN.
>
> > 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?
>
> Yes, just like it does with i-i and identityref.
>
> > If we bother to fix this problem at all, then we should get rid of
> reliance
> > on prefix to namespace mappings.
>
> Long-term, yes!
>
>
> /martin
>
>
> >
> >
> >
> >
> >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > > vladi...@transpacket.com> wrote:
> > > >
> > > > > 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 ietf-netconf-monitor...@2010-10-04.yang
> > > > >
> > > > > 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
> > > > >
> > > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > > >
> > > > >> 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
> > > > >>
> > > > >>  

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Andy Bierman  wrote:
> On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > 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.
> >
> > 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.
> >
> >
> 
> 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.

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

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

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

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

> If we bother to fix this problem at all, then we should get rid of reliance
> on prefix to namespace mappings.

Long-term, yes!


/martin


> 
> 
> 
> 
> 
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > vladi...@transpacket.com> wrote:
> > >
> > > > 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 ietf-netconf-monitor...@2010-10-04.yang
> > > >
> > > > 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
> > > >
> > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > >
> > > >> 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
> > > >>
> > > >>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
> > > >>
> > > >>
> > > >> Alternative A:
> > > >> --
> > > >>
> > > >> Use different encodings for "stream-xpath-filter" as well, depending
> > > >> on if it is XML or JSON.
> > > >>
> > > >> We would do in SN:
> > > 

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

On Thu, Oct 18, 2018 at 12:58:33PM -0700, Andy Bierman wrote:
> On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
> >
> > > 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.
> >
> > 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)?

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > 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.
>
> 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.
>
>

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.





> /martin
>
>

Andy


>
> >
> >
> > Andy
> >
> >
> > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > vladi...@transpacket.com> wrote:
> >
> > > 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 ietf-netconf-monitor...@2010-10-04.yang
> > >
> > > 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
> > >
> > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > >
> > >> 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
> > >>
> > >>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
> > >>
> > >>
> > >> Alternative A:
> > >> --
> > >>
> > >> Use different encodings for "stream-xpath-filter" as well, depending
> > >> on if it is XML or JSON.
> > >>
> > >> We would 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.
> > >>
> > >> Pro: the format is consistent within each encoding.
> > >>
> > >> Con: 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Andy Bierman  wrote:
> 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.

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


> 
> 
> Andy
> 
> 
> On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> vladi...@transpacket.com> wrote:
> 
> > 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 ietf-netconf-monitor...@2010-10-04.yang
> >
> > 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
> >
> > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> >
> >> 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
> >>
> >>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
> >>
> >>
> >> Alternative A:
> >> --
> >>
> >> Use different encodings for "stream-xpath-filter" as well, depending
> >> on if it is XML or JSON.
> >>
> >> We would 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.
> >>
> >> 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:
> >>
> >> >>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
> >>
> >>
> >> 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
> >> 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.
> >>
> >> Pro: the format is independent from the protocol encoding
> >>
> >> Con: in XML, this leaf is treated differently from other XPath
> >>   expressions, 

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
>
> > 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.
>
> 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.



>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

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

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

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

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 <
vladi...@transpacket.com> wrote:

> 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 ietf-netconf-monitor...@2010-10-04.yang
>
> 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
>
> On 10/18/18 12:30 PM, Martin Bjorklund wrote:
>
>> 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
>>
>>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
>>
>>
>> Alternative A:
>> --
>>
>> Use different encodings for "stream-xpath-filter" as well, depending
>> on if it is XML or JSON.
>>
>> We would 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.
>>
>> 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:
>>
>>>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
>>
>>
>> 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
>> 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.
>>
>> 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:
>>
>>
>>  /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>>
>>
>> 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 

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

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 ietf-netconf-monitor...@2010-10-04.yang


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

On 10/18/18 12:30 PM, Martin Bjorklund wrote:

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

   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


Alternative A:
--

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

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

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:

   
 /if:interfaces/if:interface/ip:ipv4
   

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

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:

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

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" 
 wrote:

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

  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


Alternative A:
--

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

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

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:

  
/if:interfaces/if:interface/ip:ipv4
  

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

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:

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

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


On 18/10/2018 11:30, Martin Bjorklund wrote:

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

   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


Alternative A:
--

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

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

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:

   
 /if:interfaces/if:interface/ip:ipv4
   

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

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:

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Thu, 2018-10-18 at 12:30 +0200, Martin Bjorklund wrote:
> 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
> 
>   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

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

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

It could work here, too.

Lada

> 
> 
> Alternative A:
> --
> 
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
> 
> We would 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.
> 
> 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:
> 
>  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
>   
> 
> 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
>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.
> 
> 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:
> 
>   
> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   
> 
> 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
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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

  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


Alternative A:
--

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

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

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:

  
/if:interfaces/if:interface/ip:ipv4
  

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

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:

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/15/18 4:25 PM, Ladislav Lhotka wrote:


Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:


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

On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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.

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

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.

Except some parts that don't apply. For example, siblings nodes in XPath
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



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

Lada



/martin




Lada


 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)

  

 So we need an update to RFC7951?

Regards,
Reshad.



Andy
  

 /martin





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

 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
>> > 
>> > 
>> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
>> > 
>> > wrote:
>> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>> > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
>> > > 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.
>> > >  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.
>> 
>> The thing is that XPath is "XML Path Language", so using it outside XML is
>> problematic.
>
> 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.

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

>
>
> /martin
>
>
>
>> 
>> Lada
>> 
>> > 
>> > > 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)
>> > 
>> >  
>> > >  So we need an update to RFC7951?
>> > > 
>> > > Regards,
>> > > Reshad.
>> > > 
>> > 
>> > 
>> > Andy
>> >  
>> > > /martin
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > > 
>> > > > Lada
>> > > > 
>> > > > >
>> > > > > How is this supposed to work with JSON?
>> > > > >
>> > > > >
>> > > > > /martin
>> > > > >
>> > > > > ___
>> > > > > netmod mailing list
>> > > > > netmod@ietf.org
>> > > > > https://www.ietf.org/mailman/listinfo/netmod
>> > > > 
>> > > > -- 
>> > > > Ladislav Lhotka
>> > > > Head, CZ.NIC Labs
>> > > > PGP Key ID: 0xB8F92B08A9F76C67
>> > > > 
>> > > 
>> > > ___
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > > 
>> > > 
>> > > ___
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > 
>> > 
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 

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

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

On 2018-10-12, 4:37 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Robert Wilton  wrote:
> 
> 
> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> 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 

> >> wrote:
> >>
> >>> Andy Bierman  wrote:
>  On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>> rrah...@cisco.com>
>  wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > 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.
> >  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  to 
,
> >>> where  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:
> 
>  

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton  wrote:

> Hi Andy,
> On 11/10/2018 17:52, Andy Bierman wrote:
>
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  wrote:
>
>>
>> 
>>
>>>
>>> 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.

>>> 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.
>>
>
>
> 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).
>
>
> 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
> like 'deref' that simplify syntax or extend functionality.
>
>
> 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.
>
>

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,
> Rob
>
>
Andy


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

>>> It seems the example is wrong!
>>>
>> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>> .
>>>
>>>
>>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

Hi Andy,

On 11/10/2018 17:52, Andy Bierman wrote:



On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton > wrote:






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.

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.



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


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

like 'deref' that simplify syntax or extend functionality.


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







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

It seems the example is wrong!

Please can you check section 8040, 8.3.6.  Are all the examples wrong?

Thanks,
Rob



/martin
.




Andy



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

On 12/10/2018 09:37, Martin Bjorklund wrote:

Robert Wilton  wrote:


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

Robert Wilton  wrote:

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


Andy Bierman  wrote:

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

rrah...@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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  to ,
where  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.

Why?  I.e. how is this different from stating "Custom code is needed
to connect things together"?

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.

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.


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

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 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> 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 
> >> wrote:
> >>
> >>> Andy Bierman  wrote:
>  On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>> rrah...@cisco.com>
>  wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > 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.
> >  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  to ,
> >>> where  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.
> >> Why?  I.e. how is this different from stating "Custom code is needed
> >> to connect things together"?
> > B/c the specification of XPath allows you to 

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

Hi Rob,


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




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


 Section 8.3.6 of which document?
RFC 8040.

 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





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)







 So we need an update to RFC7951?



Regards,

Reshad.





Andy





 /martin











 >

 > Lada

 >

 > >

 > > How is this supposed to work with JSON?

 > >

 > >

 > > /martin

 > >

 > > ___

 > > netmod mailing list

 > > netmod@ietf.org<mailto:netmod@ietf.org>

 > > https://www.ietf.org/mailman/listinfo/netmod

 >

 > --

 > Ladislav Lhotka

 > Head, CZ.NIC Labs

 > PGP Key ID: 0xB8F92B08A9F76C67

 >



 ___

 netmod mailing list

 netmod@ietf.org<mailto:netmod@ietf.org>

 https://www.ietf.org/mailman/listinfo/netmod





___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod



___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod

..



.







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  wrote:

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


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.



>
>> 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? :-)
>>>
>> It seems the example is wrong!
>>
> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>
> Thanks,
> Rob
>
>
>>
>> /martin
>> .
>>
>>
>

Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

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

Robert Wilton  wrote:


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


Andy Bierman  wrote:

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

rrah...@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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  to ,
where  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.

Why?  I.e. how is this different from stating "Custom code is needed
to connect things together"?

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.

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.





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

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.

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

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 11, 2018 at 9:16 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > Hi Reshad,
> >
> > Please see RW: inline.
> >
> >
> > On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> > >
> > > 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: *"netmod@ietf.org" 
> > > *Subject: *Re: [netmod] xpath expressions in JSON
> > >
> > > On 11/10/2018 11:50, Martin Bjorklund wrote:
> > >
> > > Robert Wilton <mailto:rwil...@cisco.com>wrote:
> > >
> > > On 11/10/2018 11:21, Martin Bjorklund wrote:
> > >
> > > Andy Bierman
> > > <mailto:a...@yumaworks.com>wrote:
> > >
> > > On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
> > > <mailto:m...@tail-f.com>
> > >
> > > wrote:
> > >
> > > Andy Bierman
> > > <mailto:a...@yumaworks.com
> >wrote:
> > >
> > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman
> > > (rrahman) <
> > >
> > > rrah...@cisco.com<mailto:rrah...@cisco.com>>
> > >
> > > wrote:
> > >
> > > On 2018-10-10, 9:59 AM, "netmod on behalf
> > > of Martin Bjorklund" <
> > >
> > > netmod-boun...@ietf.org netmod-boun...@ietf.org>on
> > > behalf of
> > > m...@tail-f.com<mailto:m...@tail-f.com>>
> wrote:
> > >
> > >  Ladislav Lhotka
> > > <mailto:lho...@nic.cz
> >wrote:
> > >
> > >  > Martin Bjorklund
> > > <mailto:m...@tail-f.com
> >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.
> > >
> > >  > >
> 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Reshad,
> 
> Please see RW: inline.
> 
> 
> On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> >
> > 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: *"netmod@ietf.org" 
> > *Subject: *Re: [netmod] xpath expressions in JSON
> >
> > On 11/10/2018 11:50, Martin Bjorklund wrote:
> >
> > Robert Wilton <mailto:rwil...@cisco.com>wrote:
> >
> > On 11/10/2018 11:21, Martin Bjorklund wrote:
> >
> > Andy Bierman
> > <mailto:a...@yumaworks.com>wrote:
> >
> > On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
> > <mailto:m...@tail-f.com>
> >
> > wrote:
> >
> > Andy Bierman
> > <mailto:a...@yumaworks.com>wrote:
> >
> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman
> > (rrahman) <
> >
> > rrah...@cisco.com<mailto:rrah...@cisco.com>>
> >
> > wrote:
> >
> > On 2018-10-10, 9:59 AM, "netmod on behalf
> > of Martin Bjorklund" <
> >
> > 
> > netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>on
> > behalf of
> > m...@tail-f.com<mailto:m...@tail-f.com>> wrote:
> >
> >  Ladislav Lhotka
> > <mailto:lho...@nic.cz>wrote:
> >
> >  > Martin Bjorklund
> > <mailto:m...@tail-f.com>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.
> >
> >   

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> 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 
>  wrote:
> 
> > Andy Bierman  wrote:
> >> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> > rrah...@cisco.com>
> >> wrote:
> >>
> >>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> >>> netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> >>> 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.
> >>>  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  to ,
> > where  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.
> Why?  I.e. how is this different from stating "Custom code is needed
> to connect things together"?

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.

> > 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"?
> OK, so here the module for "../foo" would need to be specified.

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

Hi Reshad,

Please see RW: inline.


On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:


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: *"netmod@ietf.org" 
*Subject: *Re: [netmod] xpath expressions in JSON

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

Robert Wilton <mailto:rwil...@cisco.com>wrote:

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

Andy Bierman
<mailto:a...@yumaworks.com>wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
<mailto:m...@tail-f.com>

wrote:

Andy Bierman
<mailto:a...@yumaworks.com>wrote:

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

rrah...@cisco.com<mailto:rrah...@cisco.com>>

wrote:

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


netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>on
behalf of
m...@tail-f.com<mailto:m...@tail-f.com>> wrote:

 Ladislav Lhotka
<mailto:lho...@nic.cz>wrote:

 > Martin Bjorklund
<mailto:m...@tail-f.com>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.

 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 sa

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

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: "netmod@ietf.org" 
Subject: Re: [netmod] xpath expressions in JSON




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

Robert Wilton <mailto:rwil...@cisco.com> wrote:



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

Andy Bierman <mailto:a...@yumaworks.com> wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
<mailto:m...@tail-f.com>

wrote:



Andy Bierman <mailto:a...@yumaworks.com> wrote:

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

rrah...@cisco.com<mailto:rrah...@cisco.com>>

wrote:



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

netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
m...@tail-f.com<mailto:m...@tail-f.com>> wrote:



 Ladislav Lhotka <mailto:lho...@nic.cz> wrote:

 > Martin Bjorklund <mailto:m...@tail-f.com> 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.

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

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



  /ietf-interfaces//ietf-ip:address[../foo]



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

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

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


Andy Bierman  wrote:

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

rrah...@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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  to ,
where  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.
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:

   /ietf-interfaces//ietf-ip:address[../foo]

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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 11:43 AM, Vladimir Vassilev wrote:


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


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




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)




 So we need an update to RFC7951?

Regards,
Reshad.



Andy



 /martin





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

 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 11:21 AM, Andy Bierman wrote:


So you must mean the full module name will be used at every node:

 
/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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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 
> >> wrote:
> >>
> >>> Andy Bierman  wrote:
>  On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>> rrah...@cisco.com>
>  wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > 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.
> >  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  to ,
> >>> where  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
> >> 

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

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

Andy Bierman  wrote:

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


Andy Bierman  wrote:

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

rrah...@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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  to ,
where  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 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> > rrah...@cisco.com>
> > > wrote:
> > >
> > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > > > 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.
> > > >  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  to ,
> > where  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.

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

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

On 11/10/2018 10:21, Andy Bierman wrote:



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


Andy Bierman mailto:a...@yumaworks.com>> wrote:
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
mailto:rrah...@cisco.com>>
> wrote:
>
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org  on
behalf of m...@tail-f.com > wrote:
> >
> >     Ladislav Lhotka mailto:lho...@nic.cz>> wrote:
> >     > Martin Bjorklund mailto:m...@tail-f.com>> 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.
> >  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  to ,
where  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.
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']
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







/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 

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 8:39 AM, Martin Bjorklund wrote:

Andy Bierman  wrote:

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


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
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.
 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  to ,
where  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)




 So we need an update to RFC7951?

Regards,
Reshad.



Andy



 /martin





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

 ___
 netmod mailing list
  

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

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

> Andy Bierman  wrote:
> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> rrah...@cisco.com>
> > wrote:
> >
> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > > 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.
> > >  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  to ,
> where  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.
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)
> >
> >
> >
> > >  So we need an update to RFC7951?
> > >
> > > Regards,
> > > Reshad.
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Lada
> > > >
> > > > >
> > > > > How is this supposed to work with JSON?
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > > 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Qin Wu  wrote:
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
> 发送时间: 2018年10月10日 20:41
> 收件人: Martin Bjorklund; netmod@ietf.org
> 主题: Re: [netmod] xpath expressions in JSON
> 
> 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 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).
> 
> [Qin]: This has been brought up before:
> 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


> 
> 2. use a module name rather than a prefix in XML, too.
> 
> I would suggest #2.
> 
> Lada
> 
> >
> > How is this supposed to work with JSON?
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
> > 
> > 
> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
> > wrote:
> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > > 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.
> > >  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.
> 
> The thing is that XPath is "XML Path Language", so using it outside XML is
> problematic.

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



> 
> Lada
> 
> > 
> > > 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)
> > 
> >  
> > >  So we need an update to RFC7951?
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > 
> > 
> > Andy
> >  
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > >
> > > > > How is this supposed to work with JSON?
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
> wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > 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.
> >  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  to ,
where  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


> 
> 
> > 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)
> 
> 
> 
> >  So we need an update to RFC7951?
> >
> > Regards,
> > Reshad.
> >
> >
> 
> Andy
> 
> 
> >
> > /martin
> >
> >
> >
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > > How is this supposed to work with JSON?
> > > >
> > > >
> > > > /martin
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
> 
> 
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
> wrote:
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> > 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.
> >  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.

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

Lada

> 
> > 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)
> 
>  
> >  So we need an update to RFC7951?
> > 
> > Regards,
> > Reshad.
> > 
> 
> 
> Andy
>  
> > /martin
> > 
> > 
> > 
> > 
> > 
> > > 
> > > Lada
> > > 
> > > >
> > > > How is this supposed to work with JSON?
> > > >
> > > >
> > > > /martin
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Qin Wu]

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

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

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

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

I would suggest #2.

Lada

>
> How is this supposed to work with JSON?
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

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

> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> netmod-boun...@ietf.org on behalf of m...@tail-f.com> 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
> 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.
>  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.


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



>  So we need an update to RFC7951?
>
> Regards,
> Reshad.
>
>

Andy


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

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" 
 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 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.
 But that means making non-backwards compatible change to the XML 
representation?

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

Regards,
Reshad.


/martin





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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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

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





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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

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

Lada

>
> How is this supposed to work with JSON?
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod