Ladislav Lhotka <lho...@nic.cz> wrote: > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote: > > Andy Bierman <a...@yumaworks.com> wrote: > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <m...@tail-f.com> wrote: > > > > > > > Hi, > > > > > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > > Andy Bierman <a...@yumaworks.com> writes: > > > > > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) < > > > > > > jason.ste...@nokia.com> wrote: > > > > > > > > > > > >> Hi all, > > > > > >> > > > > > >> > > > > > >> > > > > > >> If we have a YANG model with a leaf: > > > > > >> > > > > > >> > > > > > >> > > > > > >> MODEL VERSION 1: > > > > > >> > > > > > >> container my-model { > > > > > >> > > > > > >> leaf a { type string; } > > > > > >> > > > > > >> } > > > > > >> > > > > > >> > > > > > >> > > > > > >> And then later we produce another version of the model where that > > > > leaf is > > > > > >> placed into a choice construct: > > > > > >> > > > > > >> > > > > > >> > > > > > >> MODEL VERSION 2: > > > > > >> > > > > > >> container my-model { > > > > > >> > > > > > >> choice some-choice { > > > > > >> > > > > > >> case x { > > > > > >> > > > > > >> leaf a { type string; } > > > > > >> > > > > > >> } > > > > > >> > > > > > >> } > > > > > >> > > > > > >> } > > > > > >> > > > > > >> > > > > > >> > > > > > >> Is that considered a non-backwards-compatible change? > > > > > >> > > > > > > > > > > > > > > > > > > yes -- even though the data node /my-model/x did not change, > > > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a. > > > > > > Any leafref path pointing at this leaf will break. > > > > > > > > > > This is not correct. A leafref path is a special XPath, and as such > > > > > includes only data nodes, i.e. NOT choice and case nodes. > > > > > > > > > > What does change are schema node identifier. This could be significant > > > > > in an augment statement, but not ini this example because a leaf > > > > > cannot > > > > > be augmented anyway. > > > > > > > > > > I don't see anything else that could break, so Jason's change seems > > > > > backward compatible to me. > > > > > > > > Since it does change the schema tree, this is not legal according to > > > > 7950. So in that sense it is not backwards compatible. The rules in > > > > 7950 protect both clients and other modules that import the module. > > > > > > > > > > > This text is confusing wrt/ schema tree vs data tree: > > > > > > > > > 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>;. The leafref > > > Built-In Type > > > > > > The leafref built-in type is restricted to the value space of some > > > leaf or leaf-list node in the schema tree and optionally further > > > restricted by corresponding instance nodes in the data tree. The > > > "path" substatement (Section 9.9.2 > > > <https://tools.ietf.org/html/rfc7950#section-9.9.2>;) is used to > > > identify the referred > > > leaf or leaf-list node in the schema tree. The value space of the > > > referring node is the value space of the referred node. > > > > Yes, it should be "data tree" in both occurrences. > > I tend to disagree. The values of a leafref are first restricted according to > the *schema*, i.e. even before any leaf instance exists in the data tree that > the leafref can point to. Consider this example: > > list map { > key name; > leaf name { > type string; > } > leaf value { > type uint8; > } > } > leaf link { > type leafref { > path "../map[name='quux']/value"; > default "foo"; > } > } > > We had a long discussion about this, maybe I could find it, and the conclusion > was that a YANG parser should flag the default "foo" value as incorrect even > before any instance data are in sight.
Yes, this is correct. The quoted text needs to be rewritten to make this more clear. Altough the path refers to a (potential) node in the data tree, that node obviously has a node in the schema tree, and its value space restricts the value space of the leafref node. > I wasn't exactly happy with this conclusion because it assumes that we can use > the XPath from the argument of "path" to locate the *schema node* and check > its > type. Although it looks appealing (everybody sees what the type of "value" is, > right?), I think this is just another unfortunate example of mixing up the > schema and data instances. > > Let me ask: can we expect a newcomer to understand what's going on if even > seasoned YANG doctors get confused? Yes. I've been told that people don't read documentation or specifications and just look at examples. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod