On 24/10/2017 02:42, Andy Bierman wrote:
On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <[email protected] <mailto:[email protected]>> wrote:On 10/23/2017 01:35 PM, Martin Bjorklund wrote: Vladimir Vassilev <[email protected] <mailto:[email protected]>> wrote: Hello, I would like to use the occasion of this Errata report to point out some additional issues with the instance-identifier type definition. IMO the instance-identifier built-in type has 2 additional problems that can be addressed with alternative and significantly more radical errata or fixed in a new version of YANG.: Problem 1: The obvious limitation inherited from Xpath 1.0 - inability to escape single or double quote characters. In Xpath world this limitation is worked around by use of concat() which is not available in the YANG 1.1 instance-identifier definition. 2 examples of this limitation: 1. It is impossible to create value of type instance-identifier referencing nodes in lists with key string values containing both a single and a double quote characters e.g. ...<interface><name>"It's valid string!"</name></interface>. 2. Another example of the same problem would be a leaf of type instance-identifier referencing another leaf of type instance-identifier. With 2 references it works provided one is encoded with single quotes and the other with double but it is impossible to create third e.g. YANG: list id-list { key "id"; leaf id { type instance-identifier; } } Although the instance-identifier is problematic, it is rarely used at all, let alone using it as a list key. The XPath mixed-quotes problem is well-known, and the suggested solution seems to be use the "concat" function /foo/bar[name=concat("It's a", ' "valid" string')] Not very user friendly, is it?
I suspect that this is unlikely to be popular, but I think that it would be nice if there was a plan to move away from XPath, and define a YANG specific equivalent instead. Broadly it could follow the same format as XPath but be defined against a YANG data tree, and bind to YANG's types. We could get rid of the bits of XPath that aren't really helpful or meaningful for YANG, and add in some new functionality/fixes that are helpful to solve the YANG specific problems related to path expressions.
Rob
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
