Operating System: All
Platform: All

> in following situation

This is very similar to description of "two sibling nodes with the same local name" in https://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02#section-3.1

How does ODL distinguish "foomod:bar" from "barmod:bar" (leafs in that link), and why does it not work for distinguishing "module1:bar" from "module2:bar" (inner containers in this Bug)?

See RFC 7950 section 6.2.1:

o All leafs, leaf-lists, lists, containers, choices, rpcs, actions,
notifications, anydatas, and anyxmls defined (directly or through
a "uses" statement) within a parent node or at the top level of
the module or its submodules share the same identifier namespace.
This namespace is scoped to the parent node or module, unless the
parent node is a case node. In that case, the namespace is scoped
to the closest ancestor node that is not a case or choice node.

So, the yang defined above seems illegal as there're two 'bar' containers.

Detection of node name collision should be completed by yangtool parser, move this bug to YANGTOOLS.

https://git.opendaylight.org/gerrit/#/c/68134/

This issue has nothing to do with YangInstanceIdentifier nor organization of anything in yangtools. This concerns only the design of InstanceIdentifier, as defined in binding – SchemaContext provides all information required to make it work.

Please do not hijack issues to completely unrelated issues.

Not at all I thought, the Instance Idendifier does not need to represent Choice/Case, it's nothing to do with binding, as in description I got that why the issue created is totally because there are name collision, the immediate idea of reporter to resolve that is to reference choice/case, but that's not the root cause.

What should the binding instance identifier of choice/case's descendant data nodes finally be?
For yang snippet:

module test {
   ...
   container top {
     choice top-choice {
        case case1 {
              container cont-in-case1 { 
               }
              choice case1-choice {
                       case case11 {
                             container cont-in-case11 {
                             }
                      }
                }
        }
  }
}

module aug-test {
  ...
   augment "/test:top/top-choice/case1" {
           choice aug-case1-choice {
                       case case12 {
                             container cont-in-case12 {
                             }
                      }
             }
  }
}

1.II for 'cont-in-case1' could be:
A) InstanceIdentifier.builder(Top.class).child(ContInCase1.class) .build()or
B) InstanceIdentifier.builder(Top.class).child(TopChoice.class).child(Case1.class).child(ContInCase1.class) .build()

2.II for 'cont-in-case11' could be:
A) InstanceIdentifier.builder(Top.class).child(ContInCase11.class) or
B) InstanceIdentifier.builder(Top.class).child(TopChoice.class).child(Case1.class).child(Case1Choice.class).child(Case11.class)
.child(ContInCase11.class).build()

3.II for 'cont-in-case12' could be:
A) InstanceIdentifier.builder(Top.class).child(ContInCase12.class).build() or
B) InstanceIdentifier.builder(Top.class).child(TopChoice.class).child(Case1.class).augment(Case1Augment.class)
.child(AugCase1Choice.class).child(Case12.class).child(CintInCase12.class).build()

Since choice and case are not data tree nodes, so I prefer to choose option A).

Instance identifier should not reference choice/case.
MDSAL master: https://git.opendaylight.org/gerrit/68099

Based on the analysis done in MDSAL-45 and MDSAL-342, this issue should focus on addressability of choice/case statements only. I.e. solving the problem of 'how can I read the entire choice, so that I can decide which case it actually is?'. Note this has implications on DataTreeChangeListener: if InstanceIdentifier can address choices, we need to teach DataObjectModification how to represent a change inside a particular case and also the choice becoming a different case.

https://git.opendaylight.org/gerrit/68099