Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> 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:
>
>   <stream-xpath-filter
>       xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>     /if:interfaces/if:interface/ip:ipv4
>   </stream-xpath-filter>
>
> Example in JSON:
>
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
>
> Alternative B:
> --------------
>
> Use a non-context depending encoding, with the module name as prefix.
>
> We would do in SN:
>
>     o  The set of namespace
>        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:
>
>   <stream-xpath-filter>
>     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   </stream-xpath-filter>
>
> Example in JSON:
>
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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