Re: [YANG] so many naming scopes

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> Sec. 6.2 lists several naming scopes for various YANG constructs.
>> Most of it seems fine, except I am concerned about the confusion factor
>> that can result:
>>
>> module foo {
>>    namespace "http://example.com/foo-ns";
>>    prefix "foo";
>>    description "do you have anything without foo in it?";
>>
>>    typedef foo {
>>      type int32;
>>    }
>>
>>    grouping foo {
>>      leaf x { type foo; }
>>    }
>>
>>    container foo {
>>      leaf a { type foo; }
>>      uses foo;
>>      choice b {
>>        case foo {
>>          leaf c { type foo; }
>>        }
>>        case b {
>>          container d {
>>            uses foo;
>>          }
>>        }
>>      }
>>    }
>>
>> }
>>
>>
>> Is this much flexibility such a good idea?
> 
> Maybe not.
> 
>> I don't think the lack of individual naming scopes for every
>> type of identifier has been a big problem in the SNMP world.
> 
> No, but I don't think we should have a single flat namespace for
> identifiers like SNMP has.  I can live with one namespace per nesting
> level though.
> 

Yes, of course one naming scope (the term namespace is taken)
amongst siblings, except nested typedef and grouping names
cannot mask similar definitions within an ancestor node,
or globally within the same module.  (This part already in the draft.)

OK:

   container foo {
     container foo { ... }
   }

Not OK:

  container foo {
    typedef foo { type int32; }
    container foo {
      typedef foo { type int32; }    // invalid! masks previous typedef
      leaf foo { type foo; }
    }
  }

Only the top level definitions can be exported to other modules.
SMIv2 rules are too restrictive for XML naming, but the ability is lost
to import nested leafs like 'ifIndex' in addition to top-level objects
like 'ifTable'.  The schema-nodeid Xpath form must be used
to access such nodes (/if:ifTable/if:ifIndex).

> Earlier we had a separate namespace for rpcs and a separate for
> notifications as well, but the drawback with that was that we couldn't
> use 'augment' to augment these, so we had to have separate statements
> 'augment-rpc' and 'augment-notification'.  Having a single namespace
> actually made 'augment' more flexible.
> 
> 
> /martin
> 
> 

Andy

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang