On 12/01/2023 02:24, Fengchong (frank) wrote:
Lada,
For example:
Module a {
namespace "http://example.com/a";;
typedef instance-ref {
type leafref {
path "instances/instance/name";
}
}
container instances {
list instance {
key name;
leaf name {
type string;
}
....
}
}
}
module b import module a, and use the instance-ref defined by module a
module b {
namespace "http://example.com/b";;
import a {
prefix a;
}
list interface {
key name;
leaf name {
...
}
leaf instance {
type a:instance-ref;
}
}
}
According section 6.4.1, the namespace of names without prefix belong to the
same namespace where the typedefs are used. So,
The path instances/instance/name，the namespace of these 3 names should be
http://example.com/b, but module b have no these definitions. I think it's
unreasonable.
The meaning of author of module a should be reference the instance name defined
in module a, not module b.
So, IMO, the namespace of un-prefixed names in absolute location XPATH should
be the same with the namespace of the module where they are defined. The
context node of absolute path should be the module where they are defined.
Your path is relative, however - making your example not valid YANG with
that specific expression. You probably meant "/instances/instance/name"?
The context node is always the leaf/leaf-list for which the type is
defined, regardless of whether the path expression is relative or
absolute (Section 9.9.2.):
The "path" XPath expression is conceptually evaluated in the
following context, in addition to the definition in Section 6.4.1:
o If the "path" statement is defined within a typedef, the context
node is the leaf or leaf-list node in the data tree that
references the typedef.
o Otherwise, the context node is the node in the data tree for which
the "path" statement is defined.
A YANG author that writes their YANG with accordance to best practices
would write that expression as "/a:instances/a:instance/a:name"
(assuming prefix "a"), since RFC 8407 instructs to do so (Section 4.2.):
The following guidelines apply to prefix usage of the current (local)
module:
o The local module prefix SHOULD be used instead of no prefix in all
path expressions.
Jernej
-----邮件原件-----
发件人: Ladislav Lhotka [mailto:[email protected]]
发送时间: 2023年1月11日 15:42
收件人: Fengchong (frank) <[email protected]>; [email protected]
主题: Re: [netmod] question about name without prefix in XPath expression
Dne 11. 01. 23 v 4:16 Fengchong (frank) napsal(a):
Hi all,
In RFC 7950 section 6.4.1:
o Names without a namespace prefix belong to the same namespace
as
the identifier of the current node. Inside a grouping, that
namespace is affected by where the grouping is used (see
Section 7.13 <https://www.rfc-editor.org/rfc/rfc7950#section-7.13>).
Inside a typedef, that namespace is affected by
where the typedef is referenced. If a typedef is defined and
referenced within a grouping, the namespace is affected by
where
the grouping is used (see Section 7.13
<https://www.rfc-editor.org/rfc/rfc7950#section-7.13>).
and section 5.4:
Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not
required
to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping
in
a conventional programming language.
I think these two section have some conflicts. If groupings and
typedefs are resolved in the context where they are defined, why names
without prefix belongs to the namespace where they are used?
I don't think there is any conflict. The quoted text from 5.4 can actually be expanded as
"Grouping names, type names and identity names are resolved ..."
I may be missing something because I also don't see the XPath expression part
that you have in the subject.
Lada
The authors who defined the groupings and typedefs don’t know where
these definitions are used, they only know the place where these
definitions are defined.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
