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 prefix yang: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:
>
> <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.
>
> (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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
