Hi Rob,
Rob Shakir <r...@rob.sh> writes:
> Hi NETMOD,
>
> I am in the process of implementing draft-ietf-netmod-yang-json–08, and had
> some queries as to the content. Hopefully there is some misunderstanding on
> my part, or it helps to clean up the text for future people
> reviewing/implementing.
>
> The phrase ‘namespace-qualified’ seems to have some ambiguity through the
> document. For example, in the case that we have two modules:
>
> module mod-a {
> prefix "pfx-a";
> namespace "http://a.tld";;
>
> container container-a {
> leaf leaf-a {
> type string;
> }
>
> leaf ref-a {
> type identityref {
> base SOME_IDENTITY;
> }
> }
> }
> }
>
> module mod-b {
> prefix "pfx-b";
> namespace "http://b.tld";;
>
> container container-b {
> leaf leaf-b {
> type string;
> }
>
> leaf ref-b {
> type identityref {
> base SOME_IDENTITY;
> }
> }
> }
> }
> Then, AIUI, the encoding needs to specify the names of the modules for
> both container-a and container-b (since they sit at the
> root; and are in different namespaces) - so we encode
> these as JSON objects named mod-a:container-a and
> mod-b:container-b as per Section 4 of the document.
Correct.
>
> 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’?
Namespaces (= sets of names) as defined by YANG are
encoding-independent. However, XML and JSON use different namespace
identifiers. XML uses naturally the mechanism of [XML-NAMES], i.e. namespace
URIs
and references via declared prefixes. JSON in general doesn't support
namespaced member names, but we could conveniently use the module name
as the namespace identifier. So this is what Sec. 4 defines:
The name of a module determines the namespace of all data node names
defined in that module. If a data node is defined in a submodule,
then the namespace-qualified member name uses the name of the main
module to which the submodule belongs.
This is then later extended to other named entities such as identities.
>
> 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?
No, it's correct. YANG adopted the XML namespace rules, so declared
prefixes are used in YANG modules. The JSON-encoded name of the identity
uses the rules of the yang-json document, i.e. module name as the
namespace identifier.
> 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.
Module name is used consistently in JSON encoding, but we have to use
YANG rules when dealing with YANG modules.
It is somewhat confusing but I believe this is the best solution we
could come up with.
>
> I also didn’t understand why an identityref value encodes the
> namespace in the actual value? It seems like the “base” of the
> identityref should qualify all possible values here; with the only
> case that we would ever need this is one where we have:
I think Per explained this part nicely.
Thanks, Lada
>
> 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).
>
> Thanks,
> r.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
