ConfD User Community

Why the relative path which reference the nodes in other module doesn't work?


#1

I made two modules, one is

module try-leafref-original {
  namespace "http://tail-f.com/ns/example/try-leafref-original";
  prefix try-leafref-original;

  import tailf-common {
    prefix tailf;
  }

  list original-list {
    key my-leaf;
    leaf my-leaf {
      type string;
    }
  }
} 

Another module is

module try-leafref {
  namespace "http://tail-f.com/ns/example/try-leafref";
  prefix try-leafref;

  import tailf-common {
    prefix tailf;
  }

  import try-leafref-original {
    prefix aaa;
  }

  list reflist {
    key ref-leaf;
    leaf ref-leaf {
      type leafref {
        path "../../aaa:original-list/aaa:my-leaf";  // relative path compilation fail, but absolute path works
      }
    }
  }
}

If I use absolute path “/aaa:original-list/aaa:my-leaf”, the compilation passed without any issue. But since I changed to relative path, the compilation fail with error
error: the node ‘original-list’ from module ‘try-leafref-original’ is not found

So refering the relative path from other module is not supported ?
My confd version is 6.6.1

Thanks.


#2

I can see the same behavior. ../../ in your case should reference root node, so I guess this may be error. Is there any reason you have to use relative paths?


#3

I think “…/…/” doesn’t have to reference the root node. Since module try-leafref-original and module try-leafref are in the same level in schema tree, then the relative path “”…/…/aaa:original-list/aaa:my-leaf"" will reference the node “my-leaf” inside module try-leafref-original.

The reason I have to use the relative path is I will grouping both “try-leafref-original” and “try-leafref” and reference these two groupings in multiple places. So the absolute path won’t work, I have to use relative path.


#4

What I meant that ../../ (in your example) goes to the root, where all namespaces should be mounted.
It’s still not fully clear to me why in you scenario you just cannot start from root (/) as XPATH contains full namespace and top element of try-leafref-original module. Event for grouping this should work (unless you have more complicated scenario than in the example).


#5

Ok, the use case is like this

module try-leafref-original {
  namespace "http://tail-f.com/ns/example/try-leafref-original";
  prefix try-leafref-original;

  import tailf-common {
    prefix tailf;
  }
 grouping try-leafref-original {
  list original-list {
    key my-leaf;
    leaf my-leaf {
      type string;
    }
  }
 }
using  try-leafref-original;
} 

module try-leafref {
  namespace "http://tail-f.com/ns/example/try-leafref";
  prefix try-leafref;

  import tailf-common {
    prefix tailf;
  }

  import try-leafref-original {
    prefix aaa;
  }
grouping try-leafref {
  list reflist {
    key ref-leaf;
    leaf ref-leaf {
      type leafref {
        path "../../aaa:original-list/aaa:my-leaf";  // relative path compilation fail, but absolute path works
      }
    }
  }
}
using  try-leafref;
} 


module try-systems {
  list systems {
      key name;
      container system {
          using try-leafref-original;
          using try-leafref;
      }  
  }
}

Then I compiled try-systems.yang, try-leafref-original.yang, and try-leafref.yang.
Now you can see what I mean “reference these two groupings in multiple places”. But I will always keep these two groupings in the same level when they are referenced.

Whether this example is clear for you to understand why I have to use relative path ?


#6

Thank for more detailed example. As I also assume this should work, I have filled report with question to ConfD developers (ref. 21531). As this is only user-to-user forum, you need to contact Tail-f support if you want to assign priority to it. I’ll try to post information here, if possible.


#7

I’m afraid the more detailed example doesn’t actually show why you would want to use a relative path - the relative path “…/…/aaa:original-list/aaa:my-leaf” can, even if it worked, only ever refer to the expanded try-leafref-original grouping at the uses (not using) in module try-leafref-original, just like the absolute path “/aaa:original-list/aaa:my-leaf” does.

The expansion of the try-leafref-original grouping in module try-systems won’t even have the prefix “aaa” unless you define that prefix also for try-systems, which would be extremely confusing - groupings take on the namespace/prefix of the module where the uses is.

Bottom line, a relative path “through the root” to another module can’t buy you anything that the corresponding absolute path can’t - it can only be less useful, since it would only work when the uses is at a specific level in the module.


#8

Hi per,

Thanks for reply.

But I have a question, in my example, what I should do in the path in order to make leafref works when the grouping inside a module be “uses” in multiple places ?

Absolute path “/original-list/my-leaf” in “module try-systems” will not work since it refers the wrong “my-leaf”. It refers “my-leaf” under /original-list/my-leaf/. But I want to refer the “my-leaf” node under /systems/system/original-list/my-leaf/


#9

I’m sorry, but I don’t think there exists a way to achieve that.