On 23/10/2018 08:36, Ladislav Lhotka wrote:
Martin Bjorklund <m...@tail-f.com> writes:
Qin Wu <bill...@huawei.com> 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 <lho...@nic.cz> wrote:
Martin Bjorklund <m...@tail-f.com> 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:
<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.
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
namespace/prefix declaration, for example
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"default": true
},
{
"prefix": "ip",
"uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
}
]
it would be
/interfaces/interface[name='eth0']/ip:ipv4
which is not too bad either.
This looks verbose to me.
I would still prefer using separate encodings for XML vs JSON/CBOR
(alternative A) in the short term.
Longer term, I think that we should look at something similar to the
JSON path encoding scheme.
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
