> In this case, we never use the actual namespace (i.e., http://a.tld and
> http://b.tld) so calling it ‘namespace qualified’ appears ambiguous. Should
> it be simply referred to as ‘module-qualified’?
It is a bit of a misnomer, and perhaps could be improved, but Section 4 defines
“namespace-qualified” as “name of module”:
o namespace-qualified - the data node identifier is prefixed with
the name of the module in which the data node is defined,
separated from the data node identifier by the colon character
(":”).
> Secondarily, the example in Section 6.8 does not actually use the name of the
> module, it rather uses the prefix (if for the interface-type leaf). This
> doesn’t seem to be explained anywhere within the text. Is this a mistake?
The module is YANG, and in YANG the prefix is used, so “if” is correct. Below
the example module is a JSON snippet, where you’ll find a module’s full name
qualifying the identity.
> If it’s not (and one could encode container-a and container-b above as
> pfx-a:container-a and pfx-b:container-b), then how do we deal with this case:
> <SNIP/>
I think you’re mixing things up, JSON encoding only uses module-names.
> It seems to me that using the module name consistently throughout the
> encoding is preferable, since this cannot be different in a number of places;
> and isn’t as long as the namespace value to make readability worse.
Indeed.
> I also didn’t understand why an identityref value encodes the namespace in
> the actual value?
It can also be simple form (w/o namespace) if the identity is defined in the
same module...
> It seems like the “base” of the identityref should qualify all possible
> values here;
You mean that the namespace is implicitly defined in the YANG, so having it
also in the JSON is redundant?
> with the only case that we would ever need this is one where we have:
leaf some-reference {
type union {
type identityref {
base "a";
}
type identityref {
base "b";
}
}
}
> And a and b both define a value with the same name (where one needs the
> prefix to be able to refer to the b version).
Small nit, but I think this might be better represented using more than one
“base” statement in the identityref:
leaf some-reference {
type identityref {
base "a";
base "b";
}
}
Regardless, my only thought is that it is for consistency. I’m sure others
will have a better answer.
K.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod