On Tue, 2018-10-23 at 10:10 +0100, Robert Wilton wrote: > > 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.
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. > > I would still prefer using separate encodings for XML vs JSON/CBOR > (alternative A) in the short term. Sure, this is another decent option. Lada > > 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
