So, as best I can understand it (which isn’t much 
) You start with .. and then each parent container you want to traverse up the tree, adds another single . Or you can also use, ../.
Basically: Both .. and ../ move the point of reference to the parent container. Once there you can move to the next parent with either a single . or ../.
Some examples.
Say you have a structure of nested containers:
root
->Parent 1
->->Parent 2
->->->PeerComp
->->->ThisComp
->->Parent 3
->->->OtherComp
Example 1
To reach a custom property on PeerComp in a binding from ThisComp then you would use the following.
../PeerComp.custom.prop1
The ../ places you in the point of reference of Parent 2 Then you provide a valid Property Identifier
Example 2
To reach a custom property on Parent 2 in a binding from ThisComp then you would use the following.
../../Parent 2.custom.prop1 or .../Parent 2.custom.prop1
The first ../ from the property identifier puts you in the point of reference of Parent 2, as in Example 1, you can then use either another ../ or just . to put you in the point of reference of Parent 1. To be valid property identifiers must be of the form <name>.<scope>.<property_identifier>, so you must traverse far enough up the tree to reference the component by name (e.g. the components parent).
Example 3
To reach a custom property on Parent 1 in a binding from ThisComp then you would use the following.
../../../Parent 1.custom.prop1 or ..../Parent 1.custom.prop1
This is just a continuation of example 2. For each parent that you need to traverse up the tree you add either another ../ or . So two dots to get to the parent of this component and then an additional dot for each parent up the tree.
Example 4
Finally, if you need to get to the root then just a single / can be used. Essentially this puts you in the point of reference of the View, so To reach a custom property on root in a binding from any component then you would use the following.
/root.custom.prop1
Finally, you can only use the dot notation to travers up the tree, to come back down you must then use an absolute path. For instance, to reach a custom prop on PeerComp in a binding from OtherComp you could use the following.
.../Parent 2/PeerComp.custom.prop1
So all of that just to work through the Relative path prefix syntax.
On top of this there is also, the Absolute path prefix type, which is as you might expect the path in reference to the View, and the Shortcut path prefix type, which is the this, view, parent type paths.
Basically, the Shortcut’s are exactly that named replacements for common paths. So parent always takes you to the parent of the component you’re working with, view always takes you to the view that you are working with, and this is always to this component.
So working with our example structure we can see that
parent.custom.prop1 is equal to .../Parent 2.custom.prop1. So you could say that
parent = .../parentName
In the same way, this.custom.prop1 is equal to ../ThisComp.custom.prop1. So you could say that
this = ../componentName
However, you can’t use / or . in a shortcut prefix, so for instance from OtherComp the path
parent/Parent 2/ThisComp.custom.prop1 is invalid. This is why, parent.parent.* doesn’t work.
Instead you would need to use either the Absolute path /root/Parent 1/Parent 2/ThisComp.custom.prop1 or the Relative path
.../Parent 2/ThisComp.custom.prop1.
The only thing left of note, is that “as far as I can tell” there is no relative path that will reach the view, so the only way to reach properties on the view is to use view.custom.prop1. Likewise the only way to reach properties on the root is to use an Absolute path /root.custom.prop1.
)
I’m curious what the result will be though and if it’ll be worth the trouble at the end of it
