Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08

[Rob Shakir <[e-mail]>]

Thanks Lada and others for the responses here. Much clearer to me.

r.


On 4 March, 2016 at 5:05:03 AM, Ladislav Lhotka ([e-mail]) wrote:

Hi Rob,  

Rob Shakir <[e-mail]> 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  
> [e-mail]  
> https://www.ietf.org/mailman/listinfo/netmod  

--  
Ladislav Lhotka, CZ.NIC Labs  
PGP Key ID: E74E8C0C