Re: [yang-doctors] Fwd: Re: Issue with [e-mail] and yangdump-pro

[Andy Bierman <[e-mail]>]

On Fri, Dec 15, 2017 at 4:38 AM, Radek Krejčí <[e-mail]> wrote:

> Hi,
> I'm adding Michal Vasko to cc, he knows better how these things are
> checked in libyang.
>
> It seems to me that Andy refers the text which does not apply here. The
> identity name was used as part of XPath expresion (when-stmt), so the
> definition of the context nodes for the when-stmt (RFC 7950, sec 7.21.5)
> and XPath context rules should apply here. Not the rules for the
> identityref's base statement. In this case, the when-stmt is in augment so
> the context node (which we also understand as the current node in this
> case) is the augment's target node. And according to XPath context rules
> (RFC 7950, sec 6.4.1):
>
>  o  Names without a namespace prefix belong to the same namespace as the
> identifier of the current node.
>


I cc:ed YANG doctors to get more opinions...

The current node is the augment-stmt.
Note that it does not say context node, which is the target of the augment.
I think prefixes (and default prefix) are resolved in the module containing
the statement.


module foo {

   import bar { prefix b; }
   identity X;

   augment b:/some-node {
      leaf test {
         type string;
         when "/b:some-node/b:other-node = 'X'";
      }
   }
}

module bar {

   identity W;
   identity X { base W; }
   container some-node {
       leaf other-node {
         type identityref { base W; }
       }
   }
}

Q) Does other-node = 'X' resolve to foo:X or bar:X?  IMO: foo:X



Andy



> In this particular case, the augment node with the when-stmt augments the
> same module which defines napt44, so they are in the correct namespace and
> the identity name can be used without the prefix. So it should be fine,
> while I believe that using prefix in the cases of identities is always
> better approach. From the first sight (it may be challenging for human to
> correctly resolve the context/current node in some cases), I would also
> expect prefix.
>
> I propose to keep the change in the draft (added nat prefix), since it
> improves readability of the expression. But I don't think that it is an
> error to ommit the prefix.
>
> Regards,
> Radek
>
>
> Dne 19.11.2017 v 20:42 Benoit Claise napsal(a):
> > Hi Radek,
> >
> > Here is a bug report for you.
> >
> > Regards, Benoit
> >
> >
> > -------- Forwarded Message --------
> > Subject:      Re: Issue with [e-mail] and
> yangdump-pro
> > Date:         Sat, 18 Nov 2017 13:22:58 -0800
> > From:         Andy Bierman <[e-mail]>
> > To:   Benoit Claise <[e-mail]>
> > CC:   [e-mail] <
> [e-mail]>, Mahesh Jethanandani <
> [e-mail]>
> >
> >
> >
> > Hi,
> >
> > yangdump-pro is correct. Every other compiler missed it...
> >
> > 9.10.2.  The identityref's "base" Statement
> >
> >    The "base" statement, which is a substatement to the "type"
> >    statement, MUST be present at least once if the type is
> >    "identityref".  The argument is the name of an identity, as defined
> >    by an "identity" statement.  If a prefix is present on the identity
> >    name, it refers to an identity defined in the module that was
> >    imported with that prefix.  *Otherwise, an identity with the matching
> name MUST be defined in the current module or an included submodule.*
> >
> > Using [e-mail] and [e-mail]
> >
> > When I change 'natp44' to 'nat:natp44' in both when-stmts:
> >
> > andy@andy-homedev:~/Desktop/FD1289/IETF$ yangdump-pro
> [e-mail] modpath=.
> >
> > *** /home/andy/Desktop/FD1289/IETF/[e-mail]
> > *** 0 Errors, 0 Warnings
> >
> > andy@andy-homedev:~/Desktop/FD1289/IETF$
> >
> >
> > Andy
> >
> >
> > On Sat, Nov 18, 2017 at 11:07 AM, Benoit Claise <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     Hi Andy,
> >
> >     Can you please have a look at [e-mail] at
> http://www.claise.be/IETFYANGPageCompilation.html <http://www.claise.be/
> IETFYANGPageCompilation.html> .
> >     yangdump-pro reports a new error, while the other validators are
> fine.
> >
> >     Copying Mahesh, as YANG doctor.
> >
> >     Regards, Benoit
> >
> >
> >
>
>
>