On Thu, Nov 22, 2018 at 7:28 AM Ladislav Lhotka <lho...@nic.cz> wrote:
> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > 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.
>
> The problem with examples is that they have to stay at a trivial level
> where
> everything looks obvious and nobody has to care about subtle details such
> as the
> difference between XPath and schema node identifiers. Those who had to
> implement
> the above logic for a general case will confirm that it is pretty tricky.
>
>
I seemed to have known path-stmt was the data tree when I wrote my code ;-)
Our compiler (and pyang) complains if the choice and case nodes are given.
Because of the rule that choice and case names cannot clash with the first
real children
the schema tree expression will always identify the same node as the data
tree
(so including choice and case names is more verbose but otherwise correct)
Lada
>
Andy
>
> >
> >
> >
> > /martin
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
