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:
<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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
