From mvasko at cesnet.cz Tue Jul 4 12:53:37 2017 From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=) Date: Tue, 04 Jul 2017 14:53:37 +0200 Subject: [sysrepo-devel] libyang XPath changes Message-ID: <11d3-595b9000-b-12cc0820@133409123> Hello, today I created a pull request #889 that adjust sysrepo to recently found libyang XPath bugs. I (and it seems also everyone else working on libyang/sysrepo) misunderstood how unprefixed nodes are resolved. In short, it does not matter at all what a node's parent is, an unprefixed node uses the context module prefix. Unfortunately, this change concerns a significant part of both libyang and sysrepo so it is likely you will encounter some problems connected to these changes. For example, even for a simple subscription, you must use instead "/ietf-interfaces-interfaces/interface/ietf-ip:ipv4/mtu" the XPath "/ietf-interfaces-interfaces/interface/ietf-ip:ipv4/ietf-ip:mtu". The first node must still be prefixed because it is used to find the starting module and node and hence becomes the context node/module. That means, that whenever you are later referencing context module nodes (nodes from ietf-interfaces in this example), you can skip the prefix. However, if you are referencing nodes form another module you must ALWAYS use the prefix (nodes from ietf-ip). Now, with the mentioned pull request sysrepo devel should compile and work with current devel libyang. But, I am still looking for affected addressing in libyang, so further fixes of libyang will likely follow. Whether they will again affect sysrepo I cannot say. If they do, I will try to keep sysrepo and libyang compatible and commit changes in both simultaneously. Kind regards, Michal From fan.changhu at zte.com.cn Wed Jul 5 03:10:41 2017 From: fan.changhu at zte.com.cn (fan.changhu at zte.com.cn) Date: Wed, 5 Jul 2017 11:10:41 +0800 (CST) Subject: [sysrepo-devel] =?utf-8?q?libyang_XPath_changes?= References: 11d3-595b9000-b-12cc0820@133409123 Message-ID: <201707051110412702798@zte.com.cn> SGksCkkgc3RpbGwgdGhpbmsgdGhhdCB0aGUgdW5wcmVmaXggbm9kZSBpbiBzeXNyZXBvIEFQSSBz aG91bGQgdXNlIGl0cyBwYXJlbnQncyBwcmVmaXguIEluIGZhY3QsIHRoZXJlIGFyZSAzIGNhc2Vz IHVzaW5nIHhwYXRoOgoxLCB4cGF0aCB1c2VkIGluIHNjaGVtYSBmaWxlcywgc3VjaCBhcyBwYXRo IG9mIGxlYWZyZWYsIHNob3VsZCB1c2UgdGhlIG1vZHVsZSdzIHByZWZpeCBhcyBkZWZhdWx0LCB0 aGlzIGlzIHJlcXVpcmVkIGJ5IFJGQyA3OTUwCjIsIHhwYXRoIHVzZWQgaW4geG1sIGZpbGVzLCBz dWNoIGFzIHZhbHVlIG9mIGluc3RhbmNlLWlkZW50aWZpZXIsIGhhcyBubyBkZWZhdWx0IHByZWZp eCwgYWxsIHByZWZpeCBtdXN0IGJlIHNwZWNpZmllZCwgdGhpcyBpcyByZXF1aXJlZCBieSBSRkMg Nzk1MAozLCB4cGF0aCB1c2VkIGluIHN5c3JlcG8gQVBJLCBzdWNoIGFzIHRoZSBzdWJzY3JpcHRp b24gaW50ZXJmYWNlLCBpdCBpcyB2ZXJ5IHNwZWNpYWwsIEkgZm91bmQgaXQgd2FzIGNhbGxlZCAi bm9kZSBpZCIgaW4gdGhlIEFQSSwgaXQgc2hvdWxkIGZvbGxvdyB0aGUgSlNPTiBzcGVjaWZpY2F0 aW9uLiBSRkMgNzk1MSBkb2VzIG5vdCBkZWZpbmUgY29tbW9uIHN0eWxlIGFib3V0IHhwYXRoLCBi dXQgaXQgc2F5cyBzb21ldGhpbmcgYWJvdXQgdGhlIHZhbHVlIG9mIGluc3RhbmNlLWlkZW50aWZp ZXI6CgpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MSNzZWN0aW9uLTYuMTEKYGBg CiBGb3IgZXhhbXBsZSwKCiAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaW50ZXJmYWNlW25h bWU9J2V0aDAnXS9pZXRmLWlwOmlwdjQvaXAKCiBpcyBhIHZhbGlkIGluc3RhbmNlLWlkZW50aWZp ZXIgdmFsdWUgYmVjYXVzZSB0aGUgZGF0YSBub2RlcwogImludGVyZmFjZXMiLCAiaW50ZXJmYWNl IiwgYW5kICJuYW1lIiBhcmUgZGVmaW5lZCBpbiB0aGUgbW9kdWxlCiAiaWV0Zi1pbnRlcmZhY2Vz Iiwgd2hlcmVhcyAiaXB2NCIgYW5kICJpcCIgYXJlIGRlZmluZWQgaW4gImlldGYtaXAiLgpgYGAK CkkgdGhpbmsgd2Ugc2hvdWxkIGZvbGxvdyB0aGlzIGZvcm1hdCBpbiB0aGUgc3lzcmVwbyBBUEks IHNvIGl0IGlzIGNvcnJlY3Qgb2YgdGhlIGN1cnJlbnQgaW1wbGVtZW50LgoKCiBmYW5jaGFuZ2h1 CmZhbi5jaGFuZ2h1QHp0ZS5jb20uY24gCnd3dy56dGUuY29tLmNu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvasko at cesnet.cz Mon Jul 10 08:40:49 2017 From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=) Date: Mon, 10 Jul 2017 10:40:49 +0200 Subject: [sysrepo-devel] =?utf-8?q?libyang_XPath_changes?= In-Reply-To: <201707051110412702798@zte.com.cn> Message-ID: <4d7-59633d80-1d-cd0fa30@145861593> Hello, 1) I am not sure what you are saying here because path in leafref is defined the way I have changed it (RFC 7950 sec.9.9.2.), it is a subset of standard XPath expressions. 2) This is exactly a specific situation with an explicit deviation from the standard YANG XPath, so in this case all the node names must have prefixes, just like RFC requires, but it does not affect any other paths. 3) Like you said, XPath used in sysrepo API functions is special which means it can have whatever format we decide. In order not to define another format we decided to use the same format as for augment, which requires all external nodes to have a prefix, otherwise it is inherited from the current module, not the parent. (RFC 7950 sec.6.5.). Unfortunately, there is no "current module" when using a path in subscription functions, so there must be a mechanism to select the current module. This was solved by requiring the very first node to have a prefix, which is then subsequently used as the current module. This "extension" was always used, so there are actually no changes there. We do not like you suggestion to use JSON instance-identifier path because it is used for identifying data nodes, not schema nodes (when subscribing, you are technically selecting schema nodes). We know this is a major change and will possibly initially cause some confusion, but in the long run it is better we discovered this problem and fixed it now rather than later. Regards, Michal On Wednesday, July 5, 2017 05:10 CEST, wrote: > Hi, > I still think that the unprefix node in sysrepo API should use its parent's prefix. In fact, there are 3 cases using xpath: > 1, xpath used in schema files, such as path of leafref, should use the module's prefix as default, this is required by RFC 7950 > 2, xpath used in xml files, such as value of instance-identifier, has no default prefix, all prefix must be specified, this is required by RFC 7950 > 3, xpath used in sysrepo API, such as the subscription interface, it is very special, I found it was called "node id" in the API, it should follow the JSON specification. RFC 7951 does not define common style about xpath, but it says something about the value of instance-identifier: > > https://tools.ietf.org/html/rfc7951#section-6.11 > ``` > For example, > > /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip > > is a valid instance-identifier value because the data nodes > "interfaces", "interface", and "name" are defined in the module > "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip". > ``` > > I think we should follow this format in the sysrepo API, so it is correct of the current implement. > > > fanchanghu > fan.changhu at zte.com.cn > www.zte.com.cn From fan.changhu at zte.com.cn Mon Jul 10 12:35:54 2017 From: fan.changhu at zte.com.cn (fan.changhu at zte.com.cn) Date: Mon, 10 Jul 2017 20:35:54 +0800 (CST) Subject: [sysrepo-devel] =?utf-8?q?libyang_XPath_changes?= References: 4d7-59633d80-1d-cd0fa30@145861593 Message-ID: <201707102035549233892@zte.com.cn> SGksDQoNCjEpIE1heWJlIEkgaGF2ZSBtaXN0YWtlbiB5b3UsIHdoYXQgSSBtZWFucyBpcyBjb25z aXN0ZW50IHdpdGggeW91ciB3YXkgd2hlbiB1c2luZyBpZXRmLWlwIGFzIHRoZSBjdXJyZW50IG1v ZHVsZS4gSW4geW91ciBleGFtcGxlLCBpdCBzaG91bGQgYmUgIi9pZXRmLWludGVyZmFjZXM6aW50 ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lwdjQvbXR1IiAoaWYgdXNlZCBpbiBp ZXRmLWlwLnlhbmcpLCB5ZXM/DQoNCjIpIFdlIGhhdmUgbm8gZGlmZmVyZW5jZXMgYWJvdXQgdGhp cyBwb2ludCwgSSBqdXN0IGxpc3QgaXQgaGVyZSBhcyBhIGNhc2Ugb2YgdXNpbmcgeHBhdGguDQoN CjMpIEkgdW5kZXJzdGFuZCB3aHkgeW91IGNob29zZSBgU2NoZW1hIE5vZGUgSWRlbnRpZmllcmAg YXMgdGhlIGZvcm1hdCBpbiBzeXNyZXBvIEFQSSwgaXQgaXMgZGVmaW5lZCBpbiBSRkMsIGNsZWFy IGVub3VnaCB0byBldmVyeW9uZS4gSG93ZXZlciwgaXMgdGhpcyByZWFsbHkgZWFzeSB0byB1bmRl cnN0YW5kIG9yIHVzZT8gIEl0IGlzIG9idmlvdXMgdGhhdCBgbm9kZSBpZGAgaW4gSlNPTiBmb3Jt YXQgaXMgc2ltcGxlciwgZXNwZWNpYWxseSB3aGVuIHRoZXJlIGFyZSBwcmVkaWNhdGVzIGZvciBs aXN0IG5vZGUsIHRoaXMgbWF5IGJlIHdoeSBSRkM3OTUxIGRlZmluZWQgaXQgaW5zdGVhZCBvZiBg U2NoZW1hIE5vZGUgSWRlbnRpZmllcmAuIE9uIHRoZSBvdGhlciBoYW5kLCBgU2NoZW1hIE5vZGUg SWRlbnRpZmllcmAgaXMganVzdCBtZWFuaW5nZnVsIGluIHNjaGVtYSBmaWxlcywgdGhlcmUgYXJl IG5vIG5hbWVzcGFjZXMgYW5kIG5vICJjdXJyZW50IG1vZHVsZSIgb3V0IG9mIHRoZSBzY2hlbWEg ZmlsZSwgd2UganVzdCBtb2NrIHRoZSBmb3JtYXQgb2YgYFNjaGVtYSBOb2RlIElkZW50aWZpZXJg LCBzbyB3aGF0IHdlIHVzZWQgaXMgc3RpbGwgYSBjdXN0b20gZm9ybWF0LiAtLUlmIHdlIGhhdmUg dG8gY2hvb3NlIGEgY3VzdG9tIGZvcm1hdCwgd2h5IG5vdCB0aGUgc2ltcGxlciBvbmV+fg0KDQoN Cg0KDQoNCmZhbmNoYW5naHUNCg0KZmFuLmNoYW5naHVAenRlLmNvbS5jbg0KDQp3d3cuenRlLmNv bS5jbg== -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkrejci at cesnet.cz Tue Jul 11 07:46:32 2017 From: rkrejci at cesnet.cz (=?UTF-8?B?UmFkZWsgS3JlasSNw60=?=) Date: Tue, 11 Jul 2017 09:46:32 +0200 Subject: [sysrepo-devel] libyang XPath changes In-Reply-To: <201707102035549233892@zte.com.cn> References: <201707102035549233892@zte.com.cn> Message-ID: Hi, it's probably shorter one, if it is also simpler is more an individual opinion. From my point of view, using format intended for data tree (with the exception for predicates) on schema trees is very unexpected. Readers of this discussion, please add your feelings. We need more feedback on this. Technically, both ways are doable (despite the JSON format needs some additional work in sysrepo, but that's really not a problem). Regards, Radek Dne 10.7.2017 v 14:35 fan.changhu at zte.com.cn napsal(a): > 3) I understand why you choose `Schema Node Identifier` as the format in sysrepo API, it is defined in RFC, clear enough to everyone. However, is this really easy to understand or use? It is obvious that `node id` in JSON format is simpler, especially when there are predicates for list node, this may be why RFC7951 defined it instead of `Schema Node Identifier`. On the other hand, `Schema Node Identifier` is just meaningful in schema files, there are no namespaces and no "current module" out of the schema file, we just mock the format of `Schema Node Identifier`, so what we used is still a custom format. --If we have to choose a custom format, why not the simpler one~~ From mislav.novakovic at sartura.hr Wed Jul 12 08:47:11 2017 From: mislav.novakovic at sartura.hr (Mislav Novakovic) Date: Wed, 12 Jul 2017 10:47:11 +0200 Subject: [sysrepo-devel] libyang XPath changes In-Reply-To: References: <201707102035549233892@zte.com.cn> Message-ID: Hi, for a novice the shorter XPath format might be easier to use or simpler to understand but after a while when the user gets used to the format, there is no big difference. But in the long run I think it is important that Sysrepo and Libyang have the same format, currently I have to do some advanced logic in Sysrepo which is only possible with Libyang and it helps that they have the same format. Even if we add a API which can transform XPath format from Libyang to Sysrepo and vice versa it simply adds an additional unnecessary layer in the code logic and programmers mental processes. If we can avoid it I thin we should do it. Regards, Mislav On Tue, Jul 11, 2017 at 9:46 AM, Radek Krej?? wrote: > Hi, > it's probably shorter one, if it is also simpler is more an individual opinion. From my point of view, using format intended for data tree (with the exception for predicates) on schema trees is very unexpected. > > Readers of this discussion, please add your feelings. We need more feedback on this. Technically, both ways are doable (despite the JSON format needs some additional work in sysrepo, but that's really not a problem). > > Regards, > Radek > > > Dne 10.7.2017 v 14:35 fan.changhu at zte.com.cn napsal(a): >> 3) I understand why you choose `Schema Node Identifier` as the format in sysrepo API, it is defined in RFC, clear enough to everyone. However, is this really easy to understand or use? It is obvious that `node id` in JSON format is simpler, especially when there are predicates for list node, this may be why RFC7951 defined it instead of `Schema Node Identifier`. On the other hand, `Schema Node Identifier` is just meaningful in schema files, there are no namespaces and no "current module" out of the schema file, we just mock the format of `Schema Node Identifier`, so what we used is still a custom format. --If we have to choose a custom format, why not the simpler one~~ > > _______________________________________________ > sysrepo-devel mailing list > sysrepo-devel at sysrepo.org > http://lists.sysrepo.org/listinfo/sysrepo-devel From jan.kundrat at cesnet.cz Wed Jul 12 15:33:13 2017 From: jan.kundrat at cesnet.cz (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Wed, 12 Jul 2017 17:33:13 +0200 Subject: [sysrepo-devel] libyang XPath changes In-Reply-To: References: <201707102035549233892@zte.com.cn> Message-ID: On ?ter? 11. ?ervence 2017 9:46:32 CEST, Radek Krej?? wrote: > Readers of this discussion, please add your feelings. We need > more feedback on this. Technically, both ways are doable > (despite the JSON format needs some additional work in sysrepo, > but that's really not a problem). Just to check that I understand this discussion -- the question is about when and how to use the module prefix in node identifiers. The old way was "use a prefix whenever we cross the module boundary", i.e., /foo:a/b/c/bar:A/B/C wherere a, b, c belong to "foo" and A, B, C are from "bar". The new way which has been alredy merged into sysrepo is to do what the RFCs say, i.e., to skip the prefix if it's about the current module and if the node is not the root one. Otherwise, always use the module prefix. This means /foo:a/b/c/bar:A/bar:B/bar:C. If I understand this right, it makes sense to go the new way and follow the example of RFCs even if it means a breaking change of SR's behavior. That's what the users have tests for, right? :). I believe that there's a *huge* value in RFCs, sysrepo and libyang all using exactly one flavor of XPaths. Cheers, Jan From fan.changhu at zte.com.cn Thu Jul 13 02:11:22 2017 From: fan.changhu at zte.com.cn (fan.changhu at zte.com.cn) Date: Thu, 13 Jul 2017 10:11:22 +0800 (CST) Subject: [sysrepo-devel] =?utf-8?q?libyang_XPath_changes?= References: 201707102035549233892@zte.com.cn, da5d390a-991b-7d79-4881-2319ed00e3e3@cesnet.cz, CACmwirMHVi-zqZS-EdHufWxT90SmEO-uFfgi=BLO7fa+oVM2jQ@mail.gmail.com Message-ID: <201707131011222950286@zte.com.cn> SGksDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgaGF2ZSB0aGUgc2FtZSBmb3JtYXQgd2l0aCBM aWJ5YW5nLCBpdCBzZWVtcyBMaWJ5YW5nIGhhcyBjaGFuZ2VkIHRvIHRoaXMgd2F5IGluIHRoZSBs YXRlc3QgZGV2ZWwgYnJhbmNoIChJIGhhZCB0ZXN0ZWQgaXQganVzdCBub3cpLCBob3dldmVyLCBJ IHRoaW5rIHRoaXMgbWF5IGJlIGEgbWlzdGFrZS4NCg0KDQoNCg0KDQpGaXJzdCwgbGV0J3MgbG9v ayBhdCBob3cgTGlieWFuZyB1c2VkIHRoZSB4cGF0aCBpbiBmdW5jdGlvbiAibHlfY3R4X2dldF9u b2RlIiwgYXMgdGhlIEFQSSBzYXlzOg0KDQo+IEBwYXJhbVtpbl0gbm9kZWlkIEpTT04gc2NoZW1h IG5vZGUgaWRlbnRpZmllci4NCg0KSXQgc2VlbXMgTGlieWFuZyB3YW50cyB0byBmb2xsb3cgdGhl IEpTT04gZm9ybWF0LiANCg0KVGhlbiwgd2hhdCB0aGUgUkZDNzk1MSBzYXlzIGFib3V0ICJOYW1l cyBhbmQgTmFtZXNwYWNlcyIgaW4gSlNPTjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc5NTEjc2VjdGlvbi00DQoNCiBBIG5hbWVzcGFjZS1xdWFsaWZpZWQgbWVtYmVyIG5hbWUg TVVTVCBiZSB1c2VkIGZvciBhbGwgbWVtYmVycyBvZiBhCiB0b3AtbGV2ZWwgSlNPTiBvYmplY3Qg YW5kIHRoZW4gYWxzbyB3aGVuZXZlciB0aGUgbmFtZXNwYWNlcyBvZiB0aGUKIGRhdGEgbm9kZSBh bmQgaXRzIHBhcmVudCBub2RlIGFyZSBkaWZmZXJlbnQuIEluIGFsbCBvdGhlciBjYXNlcywgdGhl CiBzaW1wbGUgZm9ybSBvZiB0aGUgbWVtYmVyIG5hbWUgTVVTVCBiZSB1c2VkLkFsdGhvdWdoIHRo ZSBSRkMgb25seSBzYXlzIHRoYXQgdGhpcyBpcyBmb3IgIk5hbWVzIGFuZCBOYW1lc3BhY2VzIiwg SSB0aGluayB0aGlzIHJ1bGUgc2hvdWxkIGFsc28gYmUgdXNlZCBpbiBKU09OIG5vZGVpZCwgYmVj YXVzZSB0aGUgaW5zdGFuY2UtaWRlbnRpZmllciB0eXBlIGFsc28gZm9sbG93cyB0aGlzIHJ1bGUu KGRlZmluZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTEjc2VjdGlvbi02 LjExKSANCg0KDQoNCg0KU28sIElmIExpYnlhbmcgcmVhbGx5IHdhbnRzIHRvIGFjdCBhcyBpdHMg QVBJIHNheXMsIGl0IHNob3VsZCB1c2UgdGhlIG9sZGVyIGZvcm1hdCwgbm90IHRoaXMgY3VycmVu dCBvbmUuIElmIHdlIHdhbnQgdG8ga2VlcCBjb25zaXN0ZW50IHdpdGggTGlieWFuZywgd2Ugc2hv dWxkIHVzZSB0aGUgb2xkZXIgZm9ybWF0IHRvby4NCg0KDQoNCg0KDQoNCg0KDQpmYW5jaGFuZ2h1 DQoNCmZhbi5jaGFuZ2h1QHp0ZS5jb20uY24NCg0Kd3d3Lnp0ZS5jb20uY24= -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvasko at cesnet.cz Thu Jul 13 09:41:13 2017 From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=) Date: Thu, 13 Jul 2017 11:41:13 +0200 Subject: [sysrepo-devel] =?utf-8?b?Pz09P3V0Zi04P3E/ICBsaWJ5YW5nIFhQYXRo?= =?utf-8?q?_changes?= In-Reply-To: <201707131011222950286@zte.com.cn> Message-ID: <5b87-59674000-13-156ee780@57780231> Hello everyone, we have given all these XPaths and paths one more thorough and hopefully exhaustive and final thought and have come up with the text in the attachment. To briefly explain, the first section tries to summarize how all the paths used looks like, second section discusses where each of these paths is used in YANG models and YANG-modeled data, adn the last section is about libyang API and which paths where to use. The last section also includes what each function is currently doing and what changes we propose. Hopefully, it is clear enough and please reply with your opinion, whether you propose some changes or not. Also, I have not mentioned sysrepo, but it would follow the general principle from libyang probably without any changes meaning all schema paths will use LIBYANG PATH and all data paths will use JSON. Regards, Michal -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xpath.txt URL: From f.antonini at tiesse.com Thu Jul 13 15:22:51 2017 From: f.antonini at tiesse.com (fabio) Date: Thu, 13 Jul 2017 17:22:51 +0200 Subject: [sysrepo-devel] ?==?utf-8?q? libyang XPath changes In-Reply-To: <5b87-59674000-13-156ee780@57780231> References: <5b87-59674000-13-156ee780@57780231> Message-ID: Hi all From the attached file the schema is really clear. We agree with this proposal described by Michal. With regards fabio Il 13/07/2017 11:41, Michal Va?ko ha scritto: > Hello everyone, > we have given all these XPaths and paths one more thorough and hopefully exhaustive and final thought and have come up with the text in the attachment. > > To briefly explain, the first section tries to summarize how all the paths used looks like, second section discusses where each of these paths is used in YANG models and YANG-modeled data, adn the last section is about libyang API and which paths where to use. The last section also includes what each function is currently doing and what changes we propose. Hopefully, it is clear enough and please reply with your opinion, whether you propose some changes or not. > > Also, I have not mentioned sysrepo, but it would follow the general principle from libyang probably without any changes meaning all schema paths will use LIBYANG PATH and all data paths will use JSON. > > Regards, > Michal > > > _______________________________________________ > sysrepo-devel mailing list > sysrepo-devel at sysrepo.org > http://lists.sysrepo.org/listinfo/sysrepo-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fan.changhu at zte.com.cn Fri Jul 14 01:52:33 2017 From: fan.changhu at zte.com.cn (fan.changhu at zte.com.cn) Date: Fri, 14 Jul 2017 09:52:33 +0800 (CST) Subject: [sysrepo-devel] =?utf-8?q?libyang_XPath_changes?= References: 5b87-59674000-13-156ee780@57780231 Message-ID: <201707140952331724203@zte.com.cn> SGksDQoNCkl0IGlzIGNsZWFyIGVub3VnaCBub3csIGJ1dCBpdCBzdGlsbCBoYXMgYSBsaXR0bGUg Y29uZnVzaW5nIHRvIGhhdmUgdHdvIHBhdGggZm9ybWF0cyBpbiB0aGUgQVBJcywgaG93IGFib3V0 IHVzaW5nIEpTT04gaW4gYm90aCBjYXNlcz8gYWZ0ZXIgYWxsLCBhcyBpdCBpcyBzYWlkIGluIHRo ZSBhdHRhY2htZW50LCBzY2hlbWEgcGF0aCBpcyBhIHN1YnNldCBvZiBkYXRhIHBhdGgsIGlmIHdl IHVzZSB0aGUgSlNPTiAgZm9ybWF0IGFzIGRhdGEgcGF0aCwgd2UgY2FuIGFsc28gdXNlIGl0IGFz IHNjaGVtYSBwYXRoLiANCg0KQW5kLCBhcyBhbm90aGVyIGNob2ljZSwgdGhlIHByb3Bvc2FsIGlu IHRoZSBhdHRhY2htZW50IGlzIGFsc28gYWNjZXB0YWJsZSB0byBtZS4NCg0KDQoNCg0KDQoNCg0K DQoNCmZhbmNoYW5naHUNCg0KZmFuLmNoYW5naHVAenRlLmNvbS5jbg0KDQp3d3cuenRlLmNvbS5j bg== -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkrejci at cesnet.cz Fri Jul 14 08:36:28 2017 From: rkrejci at cesnet.cz (=?UTF-8?B?UmFkZWsgS3JlasSNw60=?=) Date: Fri, 14 Jul 2017 10:36:28 +0200 Subject: [sysrepo-devel] libyang XPath changes In-Reply-To: <201707140952331724203@zte.com.cn> References: <201707140952331724203@zte.com.cn> Message-ID: <9a35fe00-967f-3ff2-57d3-f22800dd88b1@cesnet.cz> Hi, currently, libyang contains, mainly due to optimizations in the simpler formats, 3 implementations of resolving some path. Using the names from the Michal's text, there are YANG XPATH (most complex not-just path), JSON (data path) and LIBYANG PATH (schema path). The YANG PATH is internally converted to LIBYANG PATH and XML to JSON. They all are defined and, more importantly, used in RFCs (ok, not LIBYANG PATH, but it is actually just an optimized YANG PATH to avoid repetitive resolving of local prefixes). The proposed JSON on schema cannot be actually implemented by the same functions as JSON on data because the tree formats differ. So we would have another (4th) implementation of go-through-tree functionality for the format which is even not used or specified in any related (talking about the schema) RFC. I would prefer to avoid this. Regards, Radek Dne 14.7.2017 v 03:52 fan.changhu at zte.com.cn napsal(a): > > Hi, > > It is clear enough now, but it still has a little confusing to have two path formats in the APIs, how about using JSON in both cases? after all, as it is said in the attachment, schema path is a subset of data path, if we use the JSON format as data path, we can also use it as schema path. > > And, as another choice, the proposal in the attachment is also acceptable to me. > > > > fanchanghu > > fan.changhu at zte.com.cn > > www.zte.com.cn > > > -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci at cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET, Association of Legal Entities Zikova 4 160 00 Praha 6 Czech Republic From fredericfran at gmail.com Fri Jul 14 10:19:52 2017 From: fredericfran at gmail.com (Frederic Francois) Date: Fri, 14 Jul 2017 11:19:52 +0100 Subject: [sysrepo-devel] Operational datastore Message-ID: Hi, I'm new to Sysrepo and I wanted to know if there is an Operational Datastore in Sysrepo by default where a data provider can publish its data for persistence. I'm aware that Sysrepo has an Operational callback feature where a data provider interface can be provided. Thank you, Frederic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvasko at cesnet.cz Fri Jul 14 10:52:36 2017 From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=) Date: Fri, 14 Jul 2017 12:52:36 +0200 Subject: [sysrepo-devel] =?utf-8?b?Pz09P3V0Zi04P3E/ICBPcGVyYXRpb25hbCBk?= =?utf-8?q?atastore?= In-Reply-To: Message-ID: <18b-5968a280-6b-72f06e80@122279206> Hello Frederic, there is no option for data provider to provide persistent state data, the callback must be used and will always be called when state data are requested so they are up-to-date. Regards, Michal On Friday, July 14, 2017 12:19 CEST, Frederic Francois wrote: > Hi, > > I'm new to Sysrepo and I wanted to know if there is an Operational > Datastore in Sysrepo by default where a data provider can publish its data > for persistence. > > I'm aware that Sysrepo has an Operational callback feature where a data > provider interface can be provided. > > Thank you, > Frederic. From fredericfran at gmail.com Fri Jul 14 13:59:13 2017 From: fredericfran at gmail.com (Frederic Francois) Date: Fri, 14 Jul 2017 14:59:13 +0100 Subject: [sysrepo-devel] Operational datastore In-Reply-To: <18b-5968a280-6b-72f06e80@122279206> References: <18b-5968a280-6b-72f06e80@122279206> Message-ID: Hi Michal, Thanks for the info. Frederic. On 14 July 2017 at 11:52, Michal Va?ko wrote: > Hello Frederic, > there is no option for data provider to provide persistent state data, the > callback must be used and will always be called when state data are > requested so they are up-to-date. > > Regards, > Michal > > On Friday, July 14, 2017 12:19 CEST, Frederic Francois < > fredericfran at gmail.com> wrote: > > > Hi, > > > > I'm new to Sysrepo and I wanted to know if there is an Operational > > Datastore in Sysrepo by default where a data provider can publish its > data > > for persistence. > > > > I'm aware that Sysrepo has an Operational callback feature where a data > > provider interface can be provided. > > > > Thank you, > > Frederic. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: